We moved to a RTC model with master always releasable, in theory.
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|## page was renamed from Merge_procedure
= Introduction =
A typical timeline might look like this:
* Release 1.3 (June)
* Create the 1.4.x release branch (June)
* Merge feature A in to 1.4.x branch
* Merge feature B in to 1.4.x branch
* Merge feature C in to 1.4.x branch
* Release 1.4
* Create 1.5.x release branch
* Merge bugfix 1 in to 1.4.x branch
* Merge bugfix 2 in to 1.4.x branch
* Merge bugfix 3 in to 1.4.x branch
* Release 1.4.1
Each one of these items is the responsibility of the Release Manager.
The developers submit merge requests for completed work to the Release Manager.
The Release Manager should follow this document when handling merge requests.
Nothing should be committed to a release branch besides what goes through this process.
If we all follow this, it will improve our code quality, test coverage, and documentation.
= Feature Branches =
Most work should happen in feature branches.
If there is not already a ticket for your work, please[[https://issues.apache.org/jira/browse/COUCHDB | create one]].
== Naming ==
Please use the ticket number, the type of the branch, along with a very short descriptive phrase, for your branch name.
If the ticket was COUCHDB-1234, and the ticket title was My Cool Feature, your branch should be called `1234-feature-cool`. If the issue is a bug and the branch includes the bug fix, it should be called `1234-fix-cool`. If `cool` are multiple words, separate them with a dash: `1234-feature-cool-stuff`.
== Git Best Practice ==
Developers are free to use a feature branch in any way they see fit during development. Prior to submitting a merge request to dev@, though, the branch should be prepared according to the following rules, as the commits on the feature branch will be a permanent part of the couchdb project's history.
A feature branch should consist of the smallest number of meaningful commits as possible. For bug fixes and small features, this is likely to be a single commit. For larger changes, multiple commits might be necessary. The guiding principle for deciding how many commits is coherence. A commit should be readable and, ideally, implement one distinct idea. A feature that requires multiple enhancements to achieve its goal should be presented as multiple commits. It is *not* necessary for the system to pass the test suite for any subset of these commits, only their combination.
= Merge Request =
The merge request is done by the developer wanting to add changes to a release branch.
If you want to make a merge request, please follow these steps:
* Prepare your code on a feature/bugfix branch.
* Add any new tests that cover your code.
* Add any new docs that cover your code.
* Run `make distcheck` a few times and verify that it works reliably.
* Send an email to [[http://mail-archives.apache.org/mod_mbox/couchdb-dev/|couchdb-dev]] mailing list. [[http://wiki.apache.org/couchdb/Merge_Request#preview | You can use this template]]. ''@@ Create template in couchdb-admin''
* Choose a subject like "[MERGE] Feature description"
* Have you added tests? If not, explain why.
* Have you added docs? If not, explain why.
* Does `make distcheck` work reliably? If not, start over.
* Ask people to check your code.
* Wait 72 hours for a lazy consensus.
* And then nudge a Release Manager if necessary!
= Merge Testing =
If someone has posted a merge request to the mailing list, you should test it.
Here are some things you can do:
* Are there any tests?
* If not, are you happy with the rationale provided?
* Are the tests good tests?
* Do the tests cover the code properly?
* Are the tests reliable?
* Do they fail on slower systems?
* Do they fail indeterminately?
* Are there any docs?
* If not, are you happy with the rationale provided?
* Are the docs good docs?
* Do the docs cover the code properly?
* Are the docs easy to understand?
* Does `make distcheck` work reliably?
* Does the code run on multiple operating systems?
* Can you test it under Linux?
* Can you test it under multiple distributions?
* Can you test it under OS X?
* Can you test it under Windows?
* Can you test it on multiple architectures?
* Can you test it under 32 bit?
* Can you test it under 64 bit?
* Can you test it on multiple interpreters?
* Can you test it on the latest Erlang?
* Can you test it on the stock Erlang?
* Can you test it on other version of Erlang?
Please look in to as much of this as possible, then send your results back to the list.
Hopefully, we can automate some of this testing at some point soon.
Do you fancy helping us with that? [[http://couchdb.apache.org/#contribute|Get in touch!]]
= Merging =
An actual merge should only be done by the active Release Manager.
Once a merge request has been tested by the community, and you are happy, you can proceed.
== Feature ==
Follow these instructions to merge a feature in to one release branch.
Feature branches are merged to release branches using 'git merge --no-ff <FEATURE BRANCH>'. This guarantees a merge commit, which are the only kinds of commit that will appear on release branches. If the merge results in conflicts, the release manager rejects the merge commit with an reply to the dev@ thread. If the merge is successful, the release manager should run 'make distcheck' and push the merge upstream if the tests pass.
== Bugfix ==
Follow these instructions to merge a bugfix in to multiple release branches.
For each release branch, 'git checkout <RELEASE BRANCH>' and 'git merge --no-ff <BUGFIX BRANCH>'. If any of the merges fail, the merge request is rejected.
== Security ==
Follow these instructions to generate a patch for unsupported releases.
(Security fixes can be merged in to supported release branches just like bugfixes.)