Armbian provides automated daily rolling releases of [small selection of images](https://github.com/armbian/os/blob/main/userpatches/targets-release-nightly.yaml) 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.
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**.
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.
- **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.
A release planning starts with an public IRC meeting where developers and interested users come together in **first Saturday, one month before the release month**.
- 00:02 - 00:05 `#topic check-in`: MC gives control to participant to check-in and wait for latecomers. If your handle is not self explanatory, add your forum/github handle and just say hi.
- 00:05 - 00:07 `#topic late topics`: MC [points out to agenda](https://docs.armbian.com/Process_Release-Model/#release-planning) and asks if there is any late topic to add.
- 00:07 - 00:09 `#topic FYI`: Stuff to know beforehand - MC presents meeting relevant news and rules of engagement:
- rule #2: If meeting is going out of desired agenda, MC will use *"STOP STOP STOP"*, wait to get attention and then proceed with the meeting agenda. **Please stop chatting and listen.**
- rule #3: Please **highlight** important information appropriately by putting a keyword in front of your message: `#info``#action``#idea``#help` check tips below.
- *Note:* board maintainers present tasks, bugs or projects they are working on (open discussion for each section if possible, otherwise MC calls people out).
- Choose upcoming release officer and next meeting organizer (1 or 2 roles). We need someone that is not well acquiented with the process to see if our documentation is good enough. He will get full support / backup, so no need to worry about anything.
- A *meetbot* will create a meeting summary at the end of the meeting. This however **heavily relys on user input**. So if you have important information to share please put a appropriate keyword in front of your message:
```
#info - Add an info item to the minutes. People should liberally use this for important things they say, so that they can be logged in the minutes.
#action - Document an action item in the minutes. Include any nicknames in the line, and the item will be assigned to them. (nicknames are case-sensitive)
#idea - Add an idea to the minutes.
#help - Add a "Call for Help" to the minutes. Use this command when you need to recruit someone to do a task.
Meeting location is IRC channel [#armbian](https://web.libera.chat/) on [Libera](https://libera.chat/). Meeting start times are announced in [Forum Events](https://forum.armbian.com/events/).
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.
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](https://forum.armbian.com/topic/12763-armbian-2002-chiru-release-thread/?tab=comments#comment-93245)
- After test images are procuded, engage in community for assistants wih testing.. forums, Twitter, etc. [share this tool](https://github.com/armbian/autotests)
