Skip to content

Home

Jump to bottom Edit New page
Tom Herbers edited this page Dec 8, 2023 · 3 revisions

Freifunk Darmstadt ‐ Firmware

General Notes

Stable Builds will be initially published in the beta autoupdater branch.

Testing Builds are independent.

Stable releases contain only devices which aren't marked as broken in Gluon. Testing releases also contain devices which are marked as broken in Gluon.

A classification as broken means that some features (wifi mesh, LEDs, ...) might not work correctly. It can also mean that it's neccesary to open the device and use an internal serial console with an UART-TTL Adapter to flash the device. The easiest way to achieve this might even be to solder a connector to the PCB. Hoewer, it should generally be doable with experience, knowledge and some risk tolerance. So a "broken=true" device should generally be mostly usuable and it doesn't mean it's necessarily only useful as a door stopper or brick after flashing.

Version Scheme

usually:

A.B(.C|~D)

but "valid" (as in in use by us) is the following:

^[0-9]\.[0-9]((\.[0-9])?~[0-9]{8}(\-[0-9a-z]{7})?|(\.[0-9]))$

# easier:
A.B((.C)?~D(-E)?|(.C))
  • A ([0-9]): Major Version
  • B ([0-9]): Minor Version
    • bumped for all Major Gluon Releases (Gluon Scheme: YYYY.R.S, for major Gluon versions YYYY.R will change)
    • stable builds: even B, followed by C
    • testing builds: odd B, followed by D
  • C: Patch Version
    • present for builds from an stable release
    • counts up
    • Reasons for patch releases: minor Gluon Release, site changes
  • D ([0-9]{8}): build date in the YYYYMMDD format
    • present for testing builds
  • E ([0-9a-z]{7}): site Commit ID
    • automatic CI Builds will have those
    • they're not shipped via the autoupater

Example for a stable Firmware: 2.6.0 Example for a testing Firmware: 2.7~20231203 Example for a CI Build Firmware: 2.7~20231205-137b2f9

Release Process

  • consensus a firmware should be released is reached (chat, plenum, ...)
  • Preparations
    • check that all relevant packages have been bumped in modules
    • check that all devices will get the correct package set in the site.mk contrib/genpkglist.py is usefull to generate the package config
  • Stable Release:
    • a Pull Request is created
      • the target branch is
        • master for minor releases (major Gluon Bumps)
        • the coresponding release Branch for patch releases
      • containing changes for:
        • README.md
        • .github/build-info.json: contains
          • the used Gluon Repo, Commit/Tag
          • the container tag in which the firmware is build
          • the targets that should be build
        • site.mk: the DEFAULT_GLUON_RELEASE needs to be modified.
          • A.B.C~$(shell date '+%Y%m%d')
    • Review and Merge of the PR
    • a tag is created and pushed on the target branch of the PR
      • (git checkout master or git checkout vYYYY.R.x)
      • ./contrib/create-release.sh 2.8.0
      • git push origin vA.B.C
      • a CI Worklow will be automatically triggered that builds the release
    • if it's a minor Release (with a major Gluon Bump):
      • the coresponding release branch is created and pushed
        • git checkout -b vYYYY.R.x master
        • git push origin vYYYY.R.x
    • Release Notes are created, they will be published in the Forum
    • initial testing by those allowed to sign firmware (but everyone else is welcome to join) once they are confident enough they will sign the beta autoupdater manifest
      • (take a look at the auotupdater section in the site.conf to see who can sign)
    • a symlink from beta to the release version is created on the Webserver
      • ln -sf vA.B.C beta
    • longer Tests on more devices
    • if everthing looks good the stable signatures are collected
    • a symlink from stable to the release version is created
      • ln -sf vA.B.C stable
    • The Forum Post is updated to note the date of the release as stable
  • 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)
        • 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
Add a custom footer
Add a custom sidebar
Clone this wiki locally