dstepanov-yadro/neoneo-go
1
0
Fork 0
forked from TrueCloudLab/neoneo-go
Code Pull requests Activity

docs: update release instruction

Browse source 
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
1 changed files with 15 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

42
docs/release-instruction.md
View file

@ -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.