Node Software Release Process

The release process begins after all features and bug fixes targeted for the next release have been tested by the developer, code reviewed via GitHub pull request, and merged into the target branch (currently "0.20"). If any new software defects are discovered at any step in the process a new issue should be created on GitHub, and the rest of the team notified. Once the defect is fixed and committed to the release branch the testing of the release should restart to ensure no new issues have been introduced. The release process steps are as follows:

1. To initiate release process, apply a git tag beta version number to the commit the release will be based off in repo at https://github.com/pocketnetteam/pocketnet.core. Example tag "0.20.17-beta1" for first 0.20.17 release - beta tag will be incremented for each critical fix applied during the release. At present, branch 0.20 is for fixes to current release version while branch 0.21 includes new feature development and porting of recent changes from Bitcoin core.
2. Open a new github issue titled "Release [version number]". The content body of the issue will include the changes present in the release, which will also double as our release notes once the release is made public. This GitHub issue will be used by the development team to track testing progress of the release.
3. Set $BUILD_TEST = xyes in configure.ac file and run "make check" on Linux to verify all unit tests pass and no test regressions have been introduced. Copy output of test results to the GitHub release issue comments, and investigate/fix any failures.
4. Build Windows and Linux version of packages and generate package checksum (Investigate automated build pipeline in future).
5. TestNet: Deploy release to one Windows node and one Linux node with the "-testnet" parameter. Verify full sync completes, node is able to connect to front end client, complete transactions, and stake.
6. Load testing: Run front-end simulation and RPC load testing against Linux and Windows testnet nodes. Record results in GitHub release issue, and investigate any performance regressions or failures encountered during testing. Both median and 99th percentile RPC request performance statistics should be recorded as part of this testing.
7. Onebox full sync/fresh install test: Development team deploys software to a node (Linux or Windows) without an existing Pocketnet Core installation or block chain to test full sync of the node with the public block chain. This ensures the consensus code of the new release is able to validate the entire block chain without error and is able to sync in a reasonable amount of time (within few days). Progress of this node should be checked every 24 hours and release should not commence until fully synced to the main network blockchain. The amount of time for the node to synchronize and any failures will be noted on the GitHub release issue.
8. Onebox Upgrade testing: Development team deploys new Pocketnet Core package to one Windows node and one Linux node using the existing blockchain data on disk. Staking should be enabled on both nodes. Run these nodes for 24 hours then verify both nodes are synced to main network without errors in log before proceeding to next step. Verify each onebox node is visible on block explorer and that block explorer functions are operational. Note completion of Onebox testing on GitHub release issue.
9. Dev Team Node Upgrade: Upgrade 50% of development team operated nodes with the new Pocketnet Core package after completion of Onebox Upgrade testing above. Run these nodes for 48 hours then verify all nodes are synced to main network without errors in log before proceeding.
10. RC release: Above steps should be completed, dev team members should check status of their nodes and sign-off that nodes are in stable and in sync with the main network in the GitHub release issue. A tag will be applied to the release branch with version number of release with the beta tag striped to indicate this is a final release version(example "0.20.xx"). At this point a RC (Release Candidate) with be posted on GitHub for community download with notification posted to the Bastyon site.
11. Stable Release: Continue running 50% of dev nodes on release package until 10 days and 1000 cumulative hours of stable operation has been achieved (minimum 4 nodes for 10 days with no errors). At this point the release on GitHub will be tagged or reposted as 'Stable' and notification will be posted to Bastyon. If critical issues are found before the stable release designation is achieved, those issues should be fixed in the next release and stable designation will not be used for the current release (process ends).
12. Stable release complete: Update remaining dev team maintained nodes to Stable release.