Release process - NetworkGradeLinux/mion-docs GitHub Wiki

  • The mion project follows a quarterly release cycle, with releases targeting December, March, June and September
  • The development process consists of planning, 10(ish) weeks of development work followed by a feature freeze after which only code that is fixing a specific issue or documentation will be merged
  • Releases are named <yocto_branch>-<year>.<month>, for example dunfell-2020.12
  • Release are code named alphabetically after the islands of Ireland
  • Mion aims to keep a stable master branch (currently dunfell) between releases - no branching strategy is used for features or releases
  • Strictly no releases on a Friday - EVER - no exceptions

Released and tagged repos:

  • mion
  • meta-mion
  • meta-mion-backports
  • meta-mion-bsp
  • meta-mion-sde
  • mion-ci
  • mion-docs
  • mion-testing

Release checklist - gating criteria

  1. All submodules have been updated recently
  2. DISTRO_VERSION have been bumped in meta-mion (see note on release names below)
  3. Latest CI run successful on release commits - and smoke-tested on hardware
  4. Release test plan has been completed, results logged and discussed as necessary
  5. All issues tagged for this release milestone have been closed or removed from the mion project board
  6. All new bugs have been triaged (important unresolved bugs must be tracked in the Errata of the release): mion project board and issues not in the project board (NOTE: make sure to update query to include any new repos)
  7. No outstanding merge requests (release repos and docs, CI, etc.)
  8. Documentation has been updated and copyright/licenses checked
  9. Release notes have been created and reviewed (see format below)

Creating the release

  • Create and push an annotated tag containing the release notes to the repos listed above
  • Create a "Release" on the top level mion repo, using the new tag and paste in the same release notes
    • It might be necessary to slightly change the formatting of the release notes here as they will be rendered as Markdown, e.g. bullet lists
  • Release notes added to the wiki under the Releases section - this should include a list of the changes per repo since the last release which can be generated using the script in the mion-ci repo
  • Release announcement by email to interested parties and notification in Slack

Post-release

  • Review test plan after release
  • Go through all of the main repos and delete the merged branches, ask all devs to clean up stale branches.

Format for annotated tags and GitHub release text

  1. Main features and improvements
  2. Notable bug fixes
  3. Errata of known issues
  4. (if required) Breaking changes and update instructions
  • Fixes, issues and anywhere else where possible, should point to an issue in the GitHub project board, e.g. (meta-mion#123)
⚠️ **GitHub.com Fallback** ⚠️