Release Process

Preperations

• Verify necessary dependencies are updated in modules

Stable Release

Stable releases are prepared using Pull Requests to the specific release branch.

Tasks

These Tasks need to be done before tagging a release.

• Update the Gluon Ref in .github/build-info.json
• Validate the used build-container matches the Gluon major version in .github/build-info.json
• Check if any targets need to be added or removed from the Target allowlist
• Bump DEFAULT_GLUON_RELEASE in site.mk to match the upcoming release version
  • NOTE: This also needs to be bumped for the master branch in case the first release for a new Gluon major version is created.

Release

After the Pull-Request is merged, the Release is created by creating a tag to the latest HEAD on the release branch. The Repository contains a convenient script for this task.

• Create the release
  • ./contrib/create-release.sh A.B.C
• Push the release
  • git push origin A.B.C

This will automatically trigger the CI build and update images to the download-server used for the firmware-selector as well as the autoupdater.

Finishing Work

• Publish Release-Notes in the Forum
• Inform your friends (or #ffda) of the new firmware release before signing beta or stable manifests.
• After enough signatures have been collected for either branch, create the respective symlink on the webserver.

Testing Releases

• Testing Releases
  • if there has been a branch of for a minor firmware version (Major Gluon Bump):
    • ffda-update-stabilizer (not relevant for patch releases)
      • Background: Devices will initally only be available in the testing branch once a stable Release is available we will (usually) publish a testing Release which automatically sets the autoupdater branch to stable
      • package has to be modified and included via GLUON_SITE_PACKAGES in the site.mk
      • a single testing Release is published with an even minor version (nodes will be switched to stable and those nodes will then autoupdate to the stable release)
        • git checkout master
        • ./contrib/create-release.sh
        • git push origin vA.B.C-YYYYMMDD
        • TODO:
          • currently the action won't recognize 2.8.0-20231208 as a testing tag because of the 0.
            • https://github.com/freifunk-darmstadt/site-ffda/blob/cd41ed13e6512bdae54a99624f1aadf63f7fe356/.github/build-meta.sh#L31
          • We could tag it as 2.8-20231208, hoewer missmatch with the site.mk, or it would require an aditional commit to modify the DEFAULT_GLUON_RELEASE. Towards the autoupdater those two should be identical
      • package is disabled again in the site for the next testing release
    • site.mk: the DEFAULT_GLUON_RELEASE is bumped to the next odd number (without a patch version)
  • .github/build-info.json: update to the desired gluon commit
  • ./contrib/create-release.sh
  • git push origin vA.B.C-YYYYMMDD