github.com/nspcc-dev/neo-go@v0.105.2-0.20240517133400-6be757af3eba/docs/release-instruction.md (about) 1 # Release instructions 2 3 This document outlines the neo-go release process. It can be used as a todo 4 list for a new release. 5 6 ## Check the state 7 8 These should run successfully: 9 * build 10 * unit-tests 11 * lint 12 * privnet with consensus nodes 13 * mainnet synchronization 14 15 ## Update CHANGELOG and ROADMAP 16 17 Add an entry to the CHANGELOG.md following the style established there. Add a 18 codename, version and release date in the heading. Write a paragraph 19 describing the most significant changes done in this release. In case if the node 20 configuration was changed, some API was marked as deprecated, any experimental 21 changes were made in the user-facing code and the users' feedback is needed or 22 if there's any other information that requires user's response, write 23 another separate paragraph for those who owns NeoGo node or uses any external 24 API. Then, add sections with release content describing each change in detail 25 and with a reference to GitHub issues and/or PRs. Minor issues that doesn't 26 affect the node end-user may be grouped under a single label. 27 * "New features" section should include new abilities that were added to the 28 node/API/services, are directly visible or available to the user and are large 29 enough to be treated as a feature. Do not include minor user-facing 30 improvements and changes that don't affect the user-facing functionality 31 even if they are new. 32 * "Behaviour changes" section should include any incompatible changes in default 33 settings, in the way commands operate or in API that are available to the 34 user. Add a note about changes user needs to make if he uses the affected code. 35 * "Improvements" section should include user-facing changes that are too 36 insignificant to be treated as a feature (e.g. new CLI flags) and are not 37 directly visible to the node end-user, such as performance optimizations, 38 refactoring and internal API changes. 39 * "Bugs fixed" section should include a set of bugs fixed since the previous 40 release with optional bug cause or consequences description. 41 42 Update ROADMAP.md if necessary. 43 44 Create a PR with CHANGELOG/ROADMAP changes, review/merge it. 45 46 ## Create a GitHub release and a tag 47 48 Use "Draft a new release" button in the "Releases" section. Create a new 49 `vX.Y.Z` tag for it following the semantic versioning standard. Put change log 50 for this release into the description. Do not attach any binaries at this step. 51 Set the "Set as the latest release" checkbox if this is the latest stable 52 release or "Set as a pre-release" if this is an unstable pre-release. 53 Press the "Publish release" button. 54 55 ## Add automatically-built binaries 56 57 New release created at the previous step triggers automatic builds (if not, 58 start them manually from the Build GitHub workflow), so wait for them to 59 finish. Built binaries should be automatically attached to the release as an 60 asset, check it on the release page. If binaries weren't attached after building 61 workflow completion, then submit the bug, download currently supported binaries 62 (at the time of writing they are `neo-go-darwin-arm64`, `neo-go-linux-amd64`, 63 `neo-go-linux-arm64` and `neo-go-windows-amd64`) from the building job artifacts, 64 unpack archives and add resulting binaries (named in the same way as archives) 65 to the previously created release via "Edit release" button. 66 67 ## Close GitHub milestone 68 69 Close corresponding X.Y.Z GitHub milestone. 70 71 ## Announcements 72 73 Copy the GitHub release page link to: 74 * Discord channel 75 * Riot channel 76 77 ## Deployment 78 79 Deploy the updated version to the mainnet/testnet.