We use semantic versioning which means that we:
- Increment the major version number every time we introduce breaking changes
- Increment the minor version number every time we add features
- Increment the bugfix version number every time we fix some bugs
If a feature release includes breaking changes, then we bump the major version number.
Historically, the project did not do this. This broke our semantic versioning promise, so we are fixing the situation.
These release cycles are designed to reduce the size of each release, making them easier to prepare.
Every three months, we will release a new feature release.
These releases will contain any new features in them since the last release, as well as any bugfixes.
If the release contains breaking changes, it will be a major release, else it will be a minor release.
Each feature release will be supported for 12 months.
Therefore, at any one particular time, there should be four supported feature releases.
Every month in-between the feature releases, we will release bugfix releases.
We will do a bugfix release for any supported feature releases, where bugfixes are available.
This may involve backporting the bugfix to four supported feature releases.
Some bugs cause major interruptions in CouchDB’s or one of its core feature’s operation for many or all users. These bugs can be classified as Critical Bugs.
When a fix exists for a critical bug, the development team can decide to make an out-of-cycle release that happens in between the timed release points.
Security fixes will be treated like critical bug fixes and released out-of-cycle.
We will distribute patches for unsupported feature releases no more than 2 years old.
Release branches are maintained in accordance with the merge procedure.