| Info |
|---|
In 2024, as of release 24.2, we moved from a major release every 6 months to a major release every 3 months. Planning happens twice a year to solicit input from users and developers, and takes the release schedule into account when planning. |
Overview
CockroachDB targets a supported major release every 6 3 months, breaking down that time period into 5 2 months of development and 1 month of stabilization. For example, v24.1 is a major release. A major release is maintained by issuing periodic patch releases to fix crashes, security issues, and data correctness issues. For example, v24.1.2 is a patch release.
In between the supported major releases, monthly alpha releases are performed for the planned next major release. For example, when v24.1 is current, v24.2-alpha.1 is an alpha release. The alpha releases see one week of testing before release and are considered unsuitable for production usage. They are intended for users who need early access to a feature before it is available in a stable release.
Timeline
The CockroachDB release cycles start on April 1 and October 1. The cycle dates were originally chosen to offset from the Go release cycle so that a major release of Go will precede a major release of CockroachDB by 2 months, though historically we have not upgraded to the latest Go release before a CockroachDB release.
The first four Historically CockroachDB released in May and November every year. In 2024, we added two /wiki/spaces/RE/pages/3554115605, released in February and August.
The first two months of a release are used for primary development work. The riskiest changes should be worked on first in order to provide the most time for discovering unexpected issues. The fifth third month sees a gradual switch from primary development to stabilization, though minor (low risk) feature development may take placewhere the only allowed changes are fixes needed to unblock delivery of a successful GA. Any high risk development needs to be signed off on by managers and TLs and that hasn’t had enough time to “bake” before the start of the stabilization period should be gated behind a setting.
...
Development: February - March
The previous release ends and development on the next release begins. Development occurs on the master branch. The new cycle does not begin if the previous cycle was delayed for any reason.
...
Focus Shift/Wind Down: Late-March - Mid-April
Primary feature development for the release begins to wind down and a focus shifts to stabilization, testing, bug fixing, and polishing. Minor feature development may take place in the fifth month of the cycle, but that work , in order to ship a beta candidate by the start of stabilization. Any minor feature development that takes place during this time should be low risk.
...
This work takes place on the master branch.
Stabilization: Mid-April - Mid-May
Feature freeze: all effort is directed towards bug fixing, and testing. This work takes place on the master branch. The release branch is cut shortly before the release in order to minimize the burden of back porting fixes. Multi person feature development can take place on feature branches.unblocking the delivery of a successful GA. This is when we cut the release branch, which minimizes the burden of backporting fixes.
Beta candidates take the place of the alpha releases and are released every week starting at the end of the fifth month. The beta releases are not expected to be bug free and should not be used in production settings where data loss or corruption cannot be tolerated. The beta releases are expected to see a decline in issues leading up to the release (i.e. later beta releases should be more stable than earlier ones).
August 15 / February 15
Planning begins for the upcoming cycle, soliciting input from users and developers.
...
Development: May - June
The previous release ends and development on the next release begins.
...
All versions post-1.0.0 should sort correctly with github.com/hashicorp/go-version and sort --version-sort. This ensures compatibility with downstream package managers’ version ordering. Note that the calver scheme is compatible with the previous semver scheme in this regard. Importantly, alphabetic components (e.g. beta, rc) can only appear after a - character, and must be separated from any following numeric components by a . character to ensure that e.g. 1.1-rc.2 sorts before 1.1-rc.10. For example, the following tags sort in the listed order:
20.1 .0 (final official major release - also named 20.1.0 internally)
20.1.0.1 (final official patch release)
120.12-alpha.1 (alpha release)
120.12-alpha.2 (alpha release, second candidatealpha)
120.12-beta.1 (beta release)
120.12-beta.2 (beta release, second beta)
120.12-rc.1 (first release candidate)
120.12-rc.2 (second release candidate)
120.1 2 (final major release)
There are some legacy cases:
...
Patch releases for the previous major release are issued periodically to fix crashes, security issues, and data correctness issues. A reasonable balance is maintained between fixing serious issues and potentially causing additional destabilization via the fix. Note that in this context, a major release corresponds to <major>.<minor> (i.e. a release that occurs every 6 3 months). Historically, patch releases for the previous major release are performed once a month. The schedule is not rigid, and faster patch releases have been performed to fix significant bugs or to work around holiday calendars. Patch releases of older major releases are issued as needed to fix serious issues that are affecting customers
For current release dates, see the CRDB Release Dashboard, which follows our Release Support Policy.
Branching
Development primarily occurs on the master branch during the last month few weeks of the previous cycle and the first four two months of the new cycle. The end of the fifth month of each latter part of this development cycle sees a freeze on feature development and a focus on testing, bug fixing, and polishing which occurs on the master branch.
Each release has a corresponding release branch named release-<major>.<minor>. Each release has a tag named v<major>.<minor>.<patch>. For example, the 24.1 .0 release has a branch named release-24.1.0 and a tag named v1v24.01.0. The 24.1.0.1 release was performed on the release-24.1.0 branch and has a tag named v1v24.01.1.