Release Model

Rolling releases

Armbian provides automated daily rolling releases of small selection of images for all supported targets. Images are available at respective board download pages: https://www.armbian.com/download. Armbian also populates its own packages repository so updates are available as an upgrade for existing installations.

Point releases

Armbian runs “train” based point releases. Whatever is ready to board the train, does so. Whatever is not has to wait for the next train. This enables us to have a predictable release cycles making it easy to plan. It also puts the responsibility on developers to make sure they have features ready on time.

Armbian releases quarterly at the end of February, May, August, November. Offset is because we all know that nothing happens for half of December. At the beginning of a release cycle, we have a planning meeting and two weeks before the end of the release we freeze integration of new features.

Release Cycle

Releases last three months. Each release starts with a meeting for planning. After planning, developers and development teams build their deliverable using whatever methods (scrum, kanban, waterfall, … ) they want but shall commit their code frequently, leading up to the last 2 weeks. The project does not accept “dumps” of code at the end. Commit early and often on master. Two weeks before the release date, we halt feature integration and only allow bug fixes. At some point during those two weeks, we start the release candidate process. This process starts by pulling a branch off master that will become the release branch. That frees up master for development on the next release. On the release candidate branch we work on bug fixes, and choose “release candidate”, RC, tags. The software at that tag is a candidate for release, and it is submitted to automated and manual tests on real hardware. If automated tests are passing, we can officially tag it as the release. If it does not, we enter another bug fix cycle and create a new release candidate. We iterate until we have a candidate that can be the formal release. Usually, this takes 2-3 cycles and 1-3 weeks of time.

Development epics, stories and bugs for each release are tracked through Jira.

Release Branching, Versioning and Tags

Branches in Armbian follow this convention:

• Main branch (main): Main development will happen on the main branch. This is the latest and greatest branch, but is always “stable” and “deployable”. All tests always pass on this branch.
• Release branch (v24.08 for example): This is a branch per release with frozen external sources.

Each Armbian release will have the following version format:

Format: <major>.<minor>.<revision>

<major> and <minor> version are incremented at the end of the release cycles while <revision> is incremented for a fix.

Release Naming

version	codename	release month	work
19.11	Vaquita	November	done
20.02	Chiru	February	done
20.05	Kagu	May	done
20.08	Caple	August	done
20.11	Tamandua	November	done
21.02	Urubu	February	done
21.05	Jerboa	May	done
21.08	Caracal	August	done
21.11	Sambar	November	cancelled
22.02	Pig	February	done
22.05	Jade	May	done
22.08	Yapok	August	done
22.11	Goral	November	done
23.02	Quoll	February	done
23.05	Suni	May	done
23.08	Colobus	August	done
23.11	Topi	November	done
24.02	Kereru	February	done
24.05	Havier	May	done
24.08	Yelt	August	done
24.11	Stirk	November	planned
25.02	Iiwi	February	planned
25.05	Caiman	May	planned
25.08	Dunnart	August	planned
25.11	Brach	November	planned
26.02	Goa	February	planned

by https://www.codenamegenerator.com from unusual animals

Release Coordinating

Summary

A release starts as a RC branch cut from main at freeze time. Once a RC branch is cut, main can be unfrozen and development can continue. RC branch is a rolling release that accepts bug fixes. The bug fixes should be cherry-picked back to main branch. Once the RC is stable, a final release as a branch named after its version. A release is never merged to main. Once a release is complete, it only should be updated for severe bugs and security vulnerabilities. A release is only maintained until the next release.

1. Forum Communication

• Create a new thread in the Armbian Project Administration forum
  • Ex topic name: Armbian 24.02 (Kereru) Release Thread
• Tag the post with relase, release version, and codename
• Use the following template to begin the body of the release thread:

Release Candidate Code Freeze Date: YYYY-MM-DD
Release Date: YYYY-MM-DD
Release Candidate Branch Link: URL
Release Changelog: URL
Release Coordinator: @yourname
Testing Tracking Sheet: https://example.com/link  (google sheets)

The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release.  Once the release is complete, this thread should be locked and unpinned. 

- Before Code Freeze – Make note in the thread the incomplete Jira issues tagged for the release example - After test images are procuded, engage in community for assistants wih testing.. forums, Twitter, etc. share this tool

2. Release Candidate Branch Management

• For code freeze – create a RC branch as version-rc ex: v20.02.0-rc
• If possible, create Jira tickets for major changes in github that were not tracked in Jira
• Begin testing process. See Release Testing
• Do not modify branch directy. Only accept PRs
• Only accept PRs for bug fixes. No features
• Update main branch version to the NEXT release version with -trunk ex. If RC is v20.02.0-rc main becomes v20.05.0-trunk
• CI testing should pass on PR
• Test images should automatically be built via Igor’s script
• Repeat build, test, and bugfix process until release is stable
• Cherry-pick bug fixes back into master
• Create Final release branch from RC

3. Release

• In Github create a release from final release branch Enable source freezing for this branch

  ./compile.sh targets
  cp output/info/git_sources.json config/sources/
  

  following by commiting this code to build framework.
• Copy release notes generated by Jira release into Github form
• Add other appropriate information into release Github release notes
• Point Armbian build system to new release
• Update Armbian documentation to reflect current release
• Celebrate