Atlantis follows a monthly release cadence to provide regular, predictable updates while maintaining stability for users.
- Frequency: Once per month
- Timing: First week OR last week of every month (but only once per month)
- Release Day: Typically Tuesday or Wednesday to allow for weekend buffer
Atlantis follows Semantic Versioning (SemVer):
- Major releases (x.0.0): Breaking changes
- Minor releases (0.x.0): New features, backward compatible
- Patch releases (0.0.x): Bug fixes and security patches
- Main branch: Contains the latest development work
- Release branches: Created for major/minor releases (e.g.,
release-0.20) - Hotfixes: Applied to both main and relevant release branches
- Release Announcements: Posted on GitHub Releases and community channels
- Breaking Changes: Clearly documented in release notes and migration guides
- Security Updates: Immediately communicated through security advisories
A release is ready when:
- ✅ All tests pass
- ✅ Documentation is updated
- ✅ Release notes are current
- ✅ No known critical bugs
- ✅ Security scan passes
- ✅ Performance benchmarks are acceptable
In case of critical security vulnerabilities or severe bugs:
- Immediate Assessment: Evaluate severity and impact
- Hotfix Development: Create targeted fix
- Expedited Testing: Focused testing on the fix
- Emergency Release: Release outside normal cadence if necessary
- Feature Requests: Submit early in the month for consideration
- Bug Reports: Report immediately for faster resolution
- Testing: Help test release candidates
- Documentation: Contribute to release notes and migration guides
For detailed information about contributing to Atlantis, see CONTRIBUTING.md.
- (Major/Minor release only) Create a new release branch
release-x.y - Go to https://github.com/runatlantis/atlantis/releases and click "Draft a new release"
- Prefix version with
vand increment based on last release. - The title of the release is the same as the tag (ex. v0.2.2)
- Fill in description by clicking on the "Generate Release Notes" button.
- You may have to manually move around some commit titles as they are determined by PR labels (see .github/labeler.yml & .github/release.yml)
- (Latest Major/Minor branches only) Make sure the release is set as latest
- Don't set "latest release" for patches on older release branches.
- Prefix version with
- Check and update the default version in
Chart.yamlin the official Helm chart as needed.
Atlantis now uses a cherry-pick-bot from Google. The bot assists in maintaining changes across releases branches by easily cherry-picking changes via pull requests.
Maintainers and Core Contributors can add a comment to a pull request:
/cherry-pick target-branch-nametarget-branch-name is the branch to cherry-pick to. cherry-pick-bot will cherry-pick the merged commit to a new branch (created from the target branch) and open a new pull request to the target branch.
The bot will immediately try to cherry-pick a merged PR. On unmerged pull request, it will not do anything immediately, but wait until merge. You can comment multiple times on a PR for multiple release branches.
The bot will fail to cherry-pick if the feature branches' git history is not linear (merge commits instead of rebase). In that case, you will need to manually cherry-pick the squashed merged commit from main to the release branch
- Switch to the release branch intended for the fix.
- Run
git cherry-pick <sha>with the commit hash from the main branch. - Push the newly cherry-picked commit up to the remote release branch.
For detailed information about past releases, see:
This document is maintained by the Atlantis maintainers. For questions about the release process, please open an issue or contact the maintainers.