Having two separate jobs is harder to maintain. Tagging and creating a
release should happen at the same time as updating the Makefile, so
do everything in one job. Rename it to be more general.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Replace shell-based date calculations with comprehensive Python script
that provides:
- Proper RC numbering counting backwards from final release dates
- Dead period detection for dates too early in the cycle
- Automated documentation updates with commit tracking
- Better error handling and testing coverage
- Shell variable output for CI integration
The new Python-based approach replaces fragile shell arithmetic with
robust datetime calculations and includes comprehensive test coverage.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <sjg@chromium.org)
Re-introduces the automatic creation of Release Candidates (RCs) into
the release workflow.
Add a new 'release:rc' that runs on the same schedule as the final
release jobs. It is designed to be mutually exclusive with the
`version:bump` job:
- On non-final-release days, it creates an RC release (e.g., 2025.07-rc1)
- On final release days, it skips its run, allowing the existing two-step
version bump and final release process to proceed.
Also tag the release, with a 'c' prefix.
Signed-off-by: Simon Glass <sjg@chromium.org>
Introduce a new CI job in .gitlab-ci-release.yml to automate the
creation of project releases.
This change implements two new jobs in .gitlab-ci-release.yml:
1. A version:bump job that runs on a schedule. On the first Monday of an
even-numbered month, it automatically updates the VERSION and PATCHLEVEL
in the Makefile and pushes the change to the master branch.
2. A release:create job that is triggered by the version bump commit. It
creates the final GitLab Release and corresponding Git tag on the commit
containing the updated Makefile.
This ensures that the repository's version is correctly updated and
committed just before the official release tag is applied, creating a
clean and reliable release history.
This single job, designed to run on a schedule, contains logic to:
- create a final release (e.g. 2025.08) on the first Monday of an
even-numbered month.
- create a release candidate (e.g. 2025.07-rc1) on all other
scheduled days.
This uses official release-cli to create both the git tag and the
corresponding GitLab Release entry automatically.
Signed-off-by: Simon Glass <sjg@chromium.org>
Introduce a new CI job in .gitlab-ci-release.yml to automate the
creation of project releases.
This single job, designed to run on a schedule, contains logic to:
- create a final release (e.g. 2025.08) on the first Monday of an
even-numbered month.
- create a release candidate (e.g. 2025.07-rc1) on all other
scheduled days.
This uses official release-cli to create both the git tag and the
corresponding GitLab Release entry automatically.
Signed-off-by: Simon Glass <sjg@chromium.org>
