code.vegaprotocol.io/vega@v0.79.0/RELEASE_PROCESS.md (about)

     1  # Release processes
     2  
     3  
     4  This document outlines the steps required in order to create a core protocol release.
     5  
     6  Please be aware of the [version numbering pattern](#version-numbering-pattern) that must be used.
     7  
     8  
     9  ## Major/minor release process
    10  
    11  1. The default branch is: `develop`.
    12  1. Create a `release/vX.Y.Z` branch off the head of **`develop`**.
    13  1. Update all readme files, changelog, and set version strings as required:
    14      - remove `Unreleased` from the changelog for the version to be released
    15      - ensure that the readme is up-to-date for the version being released
    16      - update the version number in `version/version.go`
    17      - update the version number in `protos/sources/vega/api/v1/core.proto`
    18      - update the version number in `protos/sources/vega/api/v1/corestate.proto`
    19      - update the version number in `protos/sources/datanode/api/v2/trading_data.proto`
    20      - update the version number in `protos/sources/blockexplorer/api/v1/blockexplorer.proto`
    21      - run `make proto`
    22      - run `git commit -asm "chore: release version vX.Y.Z`
    23  1. Create a pull request to merge `release/vX.Y.Z` into `master` and have it reviewed and merged
    24  1. Once the pull request has been merged, create a tag on the `master` branch
    25  1. The CI will see the tag and create all the release artifacts
    26  1. Follow the [common release process](./#common-release-process) steps
    27  
    28  
    29  ## Patch release process
    30  
    31  1. Get the patch fix pull requests merged into `develop`
    32  1. Create a `release/vX.Y.Z` branch off **`master`** or previous release branch
    33  1. Cherry pick the fixes into the `release/vX.Y.Z` branch
    34      - use the merge commit hash of a PR for the cherry picks
    35      - run `git cherry-pick -m 1 <merge commit hash>`
    36  1. Update all readme files, changelog, and set version strings as required:
    37      - ensure the changelog is correct for the patch version to be released
    38      - ensure that the readme is up-to-date for the patch version being released
    39      - update the version number in `version/version.go`
    40      - update the version number in `protos/sources/vega/api/v1/core.proto`
    41      - update the version number in `protos/sources/vega/api/v1/corestate.proto`
    42      - update the version number in `protos/sources/datanode/api/v2/trading_data.proto`
    43      - update the version number in `protos/sources/blockexplorer/api/v1/blockexplorer.proto`
    44      - run `make proto`
    45      - run `git commit -asm "chore: release version vX.Y.Z`
    46  1. Create a tag on the patch `release/vX.Y.Z` branch
    47  1. The CI will see the tag and create all the release artifacts
    48  1. Follow the [common release process](./#common-release-process) steps
    49  
    50  
    51  ## Common release process
    52  
    53  Once the above steps have been taken for the required type of release, the following steps for all releases need to be taken:
    54  
    55  1. Cut and paste the following instructions
    56     ```bash
    57     git fetch --all
    58     git checkout master
    59     git pull --rebase origin master
    60  
    61     # Create a message for the tag.
    62     # NOTE: Do not use markdown headings with '#'. Lines beginning with '#' are
    63     #       ignored by git.
    64     cat >/tmp/tagcommitmsg.txt <<-EOF
    65     Release vX.Y.Z <-- insert v$NEWVER
    66  
    67     *20YY-MM-DD*
    68  
    69     Security vulnerabilities: <-- no hashes here
    70     - #123 Fix a vulnerability
    71  
    72     Breaking changes: <-- no hashes here
    73     - #124 Rename a thing
    74  
    75     Deprecation: <-- no hashes here
    76     - #125 Deprecate a thing
    77  
    78     Improvements: <-- no hashes here
    79     - #126 Add a thing
    80  
    81     Fixes: <-- no hashes here
    82     - #126 Fix a bug
    83     EOF
    84     git tag "v$NEWVER" -F /tmp/tagcommitmsg.txt "$(git log -n1 | awk '/^commit / {print $2}')"
    85     git show "v$NEWVER" # Check the tag message
    86     git push --tags origin master
    87     # Wait for the pipeline for the tag to finish, to reduce resource contention.
    88     git checkout develop
    89     git pull --rebase origin develop
    90     git merge master
    91     git push origin develop
    92     ```
    93  1. The GitHub release notes can be auto-generated when creating/editing the release in the GitHub UI using the `Generate release notes` button:
    94      - the [`release.yml`](https://github.com/vegaprotocol/vega/blob/develop/.github/release.yml) details the headings and associated labels used to generate the release notes
    95      - check that all pull requests in the release have the correct labels paying special attention to those related to the labels `vulnerability`, `breaking-change` and `deprecation`
    96      - when all pull requests have been checked run the `Generate release notes` action
    97  1. Notify devops that the release version needs to be deployed onto the `stagnet1` environment for verification
    98  1. Notify the `@release` group on Slack in the `#engineering` channel
    99  
   100  
   101  ## Version numbering pattern
   102  
   103  To ensure no confusion between testnet (pre-release) versions and the versions deemed ready for the validators (latest), the following pattern will be used:
   104  
   105  - Mainnet ready "latest" versions: `X.Y.Z`
   106  - Staging / Testnet release candidate versions: `X.Y.Z-preview.n`
   107  
   108  Where `n` increments with each pre-release candidate version, and therefore:
   109  
   110  - `0.71.6-preview.2` is greater than `0.71.6-preview.1`
   111  - `0.71.6` is greater than `0.71.6-preview.2`
   112  - `0.72.0` is greater than `0.71.6`