mirror of
https://github.com/nspcc-dev/neo-go.git
synced 2024-11-25 13:47:19 +00:00
docs: update release instruction
It can be simplified after b27e6918bd
and
This commit is contained in:
parent
1c376ffa62
commit
1ad416a973
1 changed files with 15 additions and 27 deletions
|
@ -3,15 +3,16 @@
|
|||
This document outlines the neo-go release process. It can be used as a todo
|
||||
list for a new release.
|
||||
|
||||
## Pre-release checks
|
||||
## Check the state
|
||||
|
||||
These should run successfully:
|
||||
* build
|
||||
* unit-tests
|
||||
* lint
|
||||
* 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
|
||||
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
|
||||
operate.
|
||||
|
||||
## Updating ROADMAP
|
||||
|
||||
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
|
||||
that releasing requires admin privileges for the project). Both the `master`
|
||||
branch update and the tag must be pushed simultaneously like this:
|
||||
## Add automatically-built binaries
|
||||
|
||||
$ git push origin master v0.70.1
|
||||
|
||||
This is important to ensure proper version in a CI-built binary. Wait for
|
||||
CircleCI to build it (or them if we're to have more than one OS or
|
||||
architecture), download it and rename to `neo-go-$OS-$ARCH`, at the moment
|
||||
that should be `neo-go-linux-amd64`.
|
||||
|
||||
## 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.
|
||||
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
|
||||
finish. Then download currently supported binaries (at the time of writing
|
||||
that's `neo-go-darwin-arm64`, `neo-go-linux-amd64`, `neo-go-linux-arm64` and
|
||||
`neo-go-windows-amd64`), unpack archives and add resulting binaries (named in
|
||||
the same way as archives) to the previously created release.
|
||||
|
||||
## Close Github milestone
|
||||
|
||||
|
@ -62,9 +56,3 @@ Copy the github release page link to:
|
|||
## Deployment
|
||||
|
||||
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.
|
||||
|
|
Loading…
Reference in a new issue