FujiNet Firmware Versioning

Version numbers are manually increased by developers in the include/version.h file. This doc describes what constitutes a change to the version number and the process for pushing a new release build.

Semantic Versioning

Rules for version bumps go here

Initiate a Release Build

Release builds are triggered by pushing a Tag in the form of vXX.XX.XX where X contains digits (the version number). Any tag beginning with v will trigger a release. The build system uses the Tag description as a display for the end user to show any relevant important changes to the end user. This description should be succinct describing the most important notable changes.

In addition to the description, a change log is created in the release that can be referenced. This change log contains a bulleted list of the commit messages since the last release. It is important for developers to describe commit changes clearly so that end users and other developers can understand what changes have been made. Non descriptive messages such as Tweaks should not be used.

The following steps are to be followed when creating a release build:

1. Verify all platforms build with master branch (check Github Actions)
2. Test that all officially released platforms can boot/use firmware built from master branch (as of July 2023: ATARI, APPLE2, ADAM)
3. Modify include/version.h in master branch with new version and version date/time. Commit the change.
4. Switch to release branch: git checkout release
5. Merge with master: git merge master
6. Tag new release: git tag -a v1.0.0 -m "Short and sweet release description"
7. Push new tag: git push origin v1.0.0