| 1 | | = Branching Policy = |
| 2 | | |
| 3 | | CKAN is stored in a mercurial repo. This policy covers development and branching policy for this repo. |
| 4 | | |
| 5 | | = General: One Branch per Feature and Defect = |
| 6 | | |
| 7 | | We will be following the process described in (1) but applied to mercurial. Key aspects: |
| 8 | | |
| 9 | | 1. There will be three 'core' branches: "stable", "metastable" and "default" (in article stable=master and develop=default) |
| 10 | | * stable: stable code |
| 11 | | * metastable: (will soon be deprecated) for code preparing to be stable |
| 12 | | * default: development HEAD |
| 13 | | 2. A (named) branch will be created for each feature or defect (bug), unless it is almost certain that the ticket only requires one changeset. |
| 14 | | Branch naming convention: |
| 15 | | * defect-{ticket-number}[-optional-name] e.g. defect-902-my-bad-bug |
| 16 | | * feature-{ticket-number}[-optional-name] e.g. feature-903-my-amazing-feature |
| 17 | | 3. A (named) branch will be created for each release: release-v{release-number} e.g. release-v1.3 |
| 18 | | |
| 19 | | Feature, bug and release branches may be "closed" once appropriately merged. To summarize the work-flow: |
| 20 | | |
| 21 | | * Almost no work should be done in default or stable directly - only tickets requiring single changesets area allowed. Otherwise work in branches. |
| 22 | | * feature branches branch off default and merge back into default |
| 23 | | * defect branches branch off default *or* stable and merge back into respective branches. Fixes on stable get merged to default as appropriate. |
| 24 | | * NB: if a fix needs to go from default to stable (it happens!) then you can use mercurial's transplant (as you obviously must *not* merge from default to stable) |
| 25 | | * release branches branch off metastable (in future off stable) |
| 26 | | |
| 27 | | More in article (1). |
| 28 | | |
| 29 | | We also strongly recommend that users push *by default* to their own personal repo rather than the main repo. This allows for code review by another dev before merging into the main repo and should reduce the number of "oops, I've pushed and broken the build" moments. |
| 30 | | |
| 31 | | == Closing Branches == |
| 32 | | |
| 33 | | {{{ |
| 34 | | hg up -r {branch-name} |
| 35 | | hg ci --close-branch {branch-name} |
| 36 | | # may now want to merge to default or you'll be left with a dangling head |
| 37 | | hg up -r default |
| 38 | | hg merge -r {branch-name} |
| 39 | | }}} |
| 40 | | |
| 41 | | == Transplanting changesets == |
| 42 | | |
| 43 | | When you merge, you can't cherry pick changesets - you have to take all of them up to a certain one. In these cases transplant can be useful to copy a changeset across (though mercurial will not be aware of this copy). |
| 44 | | |
| 45 | | == 'tip' note == |
| 46 | | |
| 47 | | Mercurial tags the latest commit with the tag `tip`. This means it changes on every commit and might be on ''any'' branch. So it's best not to refer to it in documentation, emails or changeset comments. |
| 48 | | |
| 49 | | = Further references = |
| 50 | | |
| 51 | | 1. http://nvie.com/posts/a-successful-git-branching-model/ |
| 52 | | 2. http://forceten.tidalwave.it/development/mercurial-best-practices/ |
| 53 | | 3. http://www.rabbitmq.com/mercurial.html#branchperbug |
| 54 | | 4. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ |
| 55 | | 5. Original thread http://lists.okfn.org/pipermail/ckan-dev/2010-November/000034.html |
| 56 | | |
| | 1 | This is now at: http://wiki.ckan.net/Mercurial |
