The official documentation has moved to http://docs.couchdb.org — The transition is not 100% complete, but http://docs.couchdb.org should be seen as having the latest info. In some cases, the wiki still has some more or older info on certain topics inside CouchDB.
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 patch 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 bug fixes.
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 patch releases.
We will do a patch release for any supported feature releases, where patches are available.
This may involve backporting the patch 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.