-
Notifications
You must be signed in to change notification settings - Fork 39
Development and Release Workflow
New releases should have a corresponding Milestone with a list of Issues specifying the desired features (or fixes) to be added in order for that release to be deemed ready.
Once all features for a release have been merged into develop, a new release branch named release-XX.YY.0 should be branched from develop at this point and a PR should be made with the release branch targeted at main.
If new features for later releases are ready to be merged after this point, they can now safely be merged into develop while the release branch is concurrently being worked on. From this moment forward, the release branch should contain any and all bug fixes, changes to documentation to document new features, etc. necessary to stabilize and polish the release. The develop branch should NOT be merged back into the release branch, otherwise new features (or unstable code) not intended for the release could be added to it accidentally.
Once:
- all CI tests pass
- the simulator works with all new features
- the Github Pages site has been updated to reflect the changes
- and the build has been flashed to and tested on as many devices as possible
the release branch should be considered ready to merge.
Update the CHANGELOG to list all the changes, and increment the version of Krux in pyproject.toml and metadata.py to match the release.
Merge the release branch into main and delete the release branch.
Once the release is in main, verify all CI tests pass and main is GREEN. Then, pull down the changes locally and build the release using the krux script's build-release command.
For each device build, run krux sha256 releasedir/device/firmware.bin and save the hash. You'll need it to make sig files.
Fire up your own Krux device, load the private key for signing releases, and make sure the network is set to testnet. No passphrase, single-key.
Use the krux signing tool to sign the hash of each device's firmware.bin, saving it alongside as firmware.bin.sig in the releasedir folder.
Flash each build to your devices and do a final test to make sure everything is in order - do a test transaction, make sure upgrades work now that you've signed, etc.
After verifying the builds, zip the release directory and name the zip krux-vXX.YY.0.zip. Run krux sha256 krux-vXX.YY.0.zip on it and store the hash in krux-vXX.YY.0.zip.sha256.txt alongside it. Finally, sign the hash of the zip file and store it in krux-vXX.YY.0.zip.sig.
Go to GitHub > Releases, then Draft new release. Enter vXX.YY.0 as the tag name, and Version XX.YY.0 as the release title. In the description, enter the same text you put in the CHANGELOG. Upload the three files: krux-vXX.YY.0.zip, krux-vXX.YY.0.zip.sha256.txt, and krux-vXX.YY.0.zip.sig.
Publish the release!
Finally, go back to the repo and merge main into develop and resolve any conflicts.
If you have to make a hotfix to an existing release due to a security issue or a showstopper bug, make a hotfix branch branched from main, add your fix, update the CHANGELOG, and increment the version in pyproject.toml and metadata.py. The new version should simply increment the final number in the version string, for example going from XX.YY.0 to XX.YY.1.
Once all CI tests pass, merge it into main. After merging, start from Publishing and follow to the end.