hopefully switched all the svn refs out for gitty goodness
|Deletions are marked like this.||Additions are marked like this.|
|Line 22:||Line 22:|
|The master branch is where day-to-day development happens. New features and bugfixes are committed here. [[Feature Branches|http://wiki.apache.org/couchdb/Branch_management]] are merged into master in case new features have been developed in isolation.||The master branch is where day-to-day development happens. New features and bugfixes are committed here. [[Branch_management]] are merged into master in case new features have been developed in isolation.|
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.
This page describes how the CouchDB source repository is organized.
Note that the original subversion repo is no longer being maintained, CouchDB switched to git during 1.1.1 release cycle.
There are 3 ways to access CouchDB source via git:
- The canonical git://git.apache.org/couchdb.git repository using git's native protocol
The same repository is available over http in case you are behind a firewall or proxy
There is a full downstream mirror on GitHub including support for pull requests and your own forks
There's more information at Apache Git mirror. It mirrors the svn repository's structure.
(Committers should use the SSL-secured server at https://<YOUR_ASF_LOGIN>@git-wip-us.apache.org/repos/asf/couchdb.git ).
The master branch is where day-to-day development happens. New features and bugfixes are committed here. Branch_management are merged into master in case new features have been developed in isolation.
Branches that are not feature branches are release branches. Major versions are represented by the first number (z) in the version triplet. The middle number (y) denotes minor versions and the third number (z) represents bugfix releases.
Once the developers decide master is in a good state to produce a new version of CouchDB, a release branch is created with the appropriate version numbers: Say master is deemed ready to be the basis for a future 0.11.0 release (where the current release is 0.10.1), a new branch 0.11.x is created to track the development of the 0.11.x series of CouchDB releases.
Each release of major version (1.0.0, 1.0.1, ..., 1.1.0, 1.1.1, etc) is guaranteed to work in backwards compatible ways (as well as we humanly guarantee it :). New major versions may have incompatibilities. Upgrades between bugfix versions (0.11.0 to 0.11.1) should be seamless, upgrading minor or major versions might require extra work.
When the 0.11.x branch is deemed ready for a first release a new tag tags/0.11.0 is created that is a snapshot of the CouchDB source code that is the 0.11.0 release. Bugfixes to the 0.11.x line of release go into branches/0.11.x. When a new version 0.11.1 is released because enough bugfixes went into the 0.11. , a new tag tags/0.11.1 is created to snapshot the next release and so on.