docs: update release instruction

It can be simplified after b27e6918bd and
This commit is contained in:
Roman Khimov 2022-10-05 22:05:44 +03:00
parent 1c376ffa62
commit 1ad416a973

View file

@ -3,15 +3,16 @@
This document outlines the neo-go release process. It can be used as a todo This document outlines the neo-go release process. It can be used as a todo
list for a new release. list for a new release.
## Pre-release checks ## Check the state
These should run successfully: These should run successfully:
* build * build
* unit-tests * unit-tests
* lint * lint
* privnet with consensus nodes * privnet with consensus nodes
* mainnet synchronization
## Writing CHANGELOG ## Update CHANGELOG and ROADMAP
Add an entry to the CHANGELOG.md following the style established there. Add a Add an entry to the CHANGELOG.md following the style established there. Add a
codename, version and release date in the heading. Write a paragraph codename, version and release date in the heading. Write a paragraph
@ -23,31 +24,24 @@ optimizations, refactoring and API changes. Add a "Behaviour changes" section
if there are any incompatible changes in default settings or the way commands if there are any incompatible changes in default settings or the way commands
operate. operate.
## Updating ROADMAP
Update ROADMAP.md if necessary. Update ROADMAP.md if necessary.
## Tag the release Create a PR with CHANGELOG/ROADMAP changes, review/merge it.
Use `vX.Y.Z` tag following the semantic versioning standard. ## Create a Github release and a tag
## Push changes and release tag to Github Use "Draft a new release" button in the "Releases" section. Create a new
`vX.Y.Z` tag for it following the semantic versioning standard. Put change log
for this release into the description. Do not attach any binaries at this step.
This step should bypass the default PR mechanism to get a correct result (so ## Add automatically-built binaries
that releasing requires admin privileges for the project). Both the `master`
branch update and the tag must be pushed simultaneously like this:
$ git push origin master v0.70.1 New release created at the previous step triggers automatic builds (if not,
start them manually from the Build Github workflow), so wait for them to
This is important to ensure proper version in a CI-built binary. Wait for finish. Then download currently supported binaries (at the time of writing
CircleCI to build it (or them if we're to have more than one OS or that's `neo-go-darwin-arm64`, `neo-go-linux-amd64`, `neo-go-linux-arm64` and
architecture), download it and rename to `neo-go-$OS-$ARCH`, at the moment `neo-go-windows-amd64`), unpack archives and add resulting binaries (named in
that should be `neo-go-linux-amd64`. the same way as archives) to the previously created release.
## Make a proper Github release
Edit an automatically-created release on Github, copy things from changelog
there and attach previously downloaded binary. Make a release.
## Close Github milestone ## Close Github milestone
@ -62,9 +56,3 @@ Copy the github release page link to:
## Deployment ## Deployment
Deploy the updated version to the mainnet/testnet. Deploy the updated version to the mainnet/testnet.
## Post-release
The first commit after the release must be tagged with `X.Y.Z+1-pre` tag for
proper semantic-versioned builds. So, it's good to make some minor
documentation update after the release and push it with this new tag.