forked from TrueCloudLab/neoneo-go
Merge pull request #2789 from nspcc-dev/release-instr-upd
docs: update release instructions
This commit is contained in:
commit
b930a970ce
1 changed files with 32 additions and 13 deletions
|
@ -16,40 +16,59 @@ These should run successfully:
|
||||||
|
|
||||||
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
|
||||||
describing the most significant changes done in this release. Then, add
|
describing the most significant changes done in this release. In case if the node
|
||||||
sections with new features implemented and bugs fixed describing each change in detail and
|
configuration was changed, some API was marked as deprecated, any experimental
|
||||||
with a reference to Github issues. Add generic improvements section for
|
changes were made in the user-facing code and the users' feedback is needed or
|
||||||
changes that are not directly visible to the node end-user, such as performance
|
if there's any other information that requires user's response, write
|
||||||
optimizations, refactoring and API changes. Add a "Behaviour changes" section
|
another separate paragraph for those who owns NeoGo node or uses any external
|
||||||
if there are any incompatible changes in default settings or the way commands
|
API. Then, add sections with release content describing each change in detail
|
||||||
operate.
|
and with a reference to GitHub issues and/or PRs. Minor issues that doesn't
|
||||||
|
affect the node end-user may be grouped under a single label.
|
||||||
|
* "New features" section should include new abilities that were added to the
|
||||||
|
node/API/services, are directly visible or available to the user and are large
|
||||||
|
enough to be treated as a feature. Do not include minor user-facing
|
||||||
|
improvements and changes that don't affect the user-facing functionality
|
||||||
|
even if they are new.
|
||||||
|
* "Behaviour changes" section should include any incompatible changes in default
|
||||||
|
settings, in the way commands operate or in API that are available to the
|
||||||
|
user. Add a note about changes user needs to make if he uses the affected code.
|
||||||
|
* "Improvements" section should include user-facing changes that are too
|
||||||
|
insignificant to be treated as a feature (e.g. new CLI flags) and are not
|
||||||
|
directly visible to the node end-user, such as performance optimizations,
|
||||||
|
refactoring and internal API changes.
|
||||||
|
* "Bugs fixed" section should include a set of bugs fixed since the previous
|
||||||
|
release with optional bug cause or consequences description.
|
||||||
|
|
||||||
Update ROADMAP.md if necessary.
|
Update ROADMAP.md if necessary.
|
||||||
|
|
||||||
Create a PR with CHANGELOG/ROADMAP changes, review/merge it.
|
Create a PR with CHANGELOG/ROADMAP changes, review/merge it.
|
||||||
|
|
||||||
## Create a Github release and a tag
|
## Create a GitHub release and a tag
|
||||||
|
|
||||||
Use "Draft a new release" button in the "Releases" section. Create a new
|
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
|
`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.
|
for this release into the description. Do not attach any binaries at this step.
|
||||||
|
Set the "Set as the latest release" checkbox if this is the latest stable
|
||||||
|
release or "Set as a pre-release" if this is an unstable pre-release.
|
||||||
|
Press the "Publish release" button.
|
||||||
|
|
||||||
## Add automatically-built binaries
|
## Add automatically-built binaries
|
||||||
|
|
||||||
New release created at the previous step triggers automatic builds (if not,
|
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
|
start them manually from the Build GitHub workflow), so wait for them to
|
||||||
finish. Then download currently supported binaries (at the time of writing
|
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
|
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
|
`neo-go-windows-amd64`), unpack archives and add resulting binaries (named in
|
||||||
the same way as archives) to the previously created release.
|
the same way as archives) to the previously created release via "Edit release"
|
||||||
|
button.
|
||||||
|
|
||||||
## Close Github milestone
|
## Close GitHub milestone
|
||||||
|
|
||||||
Close corresponding X.Y.Z Github milestone.
|
Close corresponding X.Y.Z GitHub milestone.
|
||||||
|
|
||||||
## Announcements
|
## Announcements
|
||||||
|
|
||||||
Copy the github release page link to:
|
Copy the GitHub release page link to:
|
||||||
* Discord channel
|
* Discord channel
|
||||||
* Riot channel
|
* Riot channel
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue