Automating the U-Boot Concept Release Cycle

U-Boot Concept releases provide regular, time-based snapshots of our development progress, offering a stable point for users and developers. Up until recently, creating these releases involved a series of manual steps that were time-consuming and prone to human error.

To improve this process, we’re happy to announce a new, fully automated release workflow for U-Boot Concept. This system uses GitLab CI/CD and a custom Python script to handle the entire release process, from version calculation to final tagging, ensuring consistency and reliability.

A Predictable Schedule

The automation is built around a strict, predictable schedule that defines when final and release candidate (RC) versions are created. This removes any ambiguity about when to expect a new release.

• Final Releases: Occur on the first Monday of every even-numbered month (February, April, June, August, October, December). The version number corresponds to the year and month, such as 2025.10.
• Release Candidates (RCs): A series of three release candidates are created every two weeks leading up to a final release:
  • rc1: 6 weeks before the final release.
  • rc2: 4 weeks before the final release.
  • rc3: 2 weeks before the final release.
• Dead Period: The time between a final release and the next rc1 is considered a “dead period” where no automated releases occur. This provides a development window before the next stabilization cycle begins.

The Automation in Action

The entire process is managed by a scheduled GitLab CI/CD pipeline that runs periodically to check if a release is due. Here’s a step-by-step look at what happens on a release day:

1. Date Check & Version Calculation: The pipeline executes a Python script (scripts/release_version.py), which acts as the brains of the operation. The script checks the current date against the release schedule. If it’s not a designated release Monday, the job simply exits.
2. Makefile Version Bump: If it is a release day, the script calculates the new version (e.g., 2025.12-rc1) and automatically updates the VERSION, PATCHLEVEL, and EXTRAVERSION variables in the project’s Makefile.
3. Automated Commit: The CI job commits the modified Makefile directly to the master branch with a standardized message, such as chore: Bump version for release candidate 2025.12-rc1.
4. Documentation Update: The script then updates the release history in doc/develop/concept_releases.rst, adding an entry for the new version along with the corresponding commit SHA. It also intelligently updates the “Next Release” section to show the schedule for the upcoming final release. This change is also committed and pushed automatically.
5. Tag and Release: Finally, the pipeline uses the official release-cli tool to create a formal Git tag (e.g., c2025.12-rc1) and a corresponding GitLab Release. This provides a clear, permanent marker for the release, complete with a title and description. The ‘c’ prefix makes it clear that this is a Concept release, not the main tree.

Benefits of Automation

This new workflow brings several key advantages to the U-Boot Concept project:

• Consistency: Every release is generated using the exact same procedure, ensuring uniformity.
• Reliability: The risk of human error—like typos in version numbers or forgetting a step—is eliminated.
• Transparency: The entire process is defined in code, and the release history is now automatically documented and kept up-to-date for everyone to see.
• Efficiency: Developer time is freed from the manual chores of release management, allowing more focus on development and innovation.

This move to an automated system marks a significant step in improving our release management and ensuring that U-Boot Concept remains a dependable and predictable development platform.