[ckan-dev] New branching and repository policy

Rufus Pollock rufus.pollock at okfn.org
Thu Nov 25 09:04:52 GMT 2010


Hi All (and especially CKAN committers),

Following discussion at the sprint last week it is proposed we adopt a
new branching and repository policy along the following lines.

This is not yet finalized so if you have suggestions or feedback please say.

Regards,

Rufus

## Branch-per-feature, per-bug and per-releass

We will be following the process described
<http://nvie.com/posts/a-successful-git-branching-model/> but applied
to mercurial. Key aspects:

1. There will be two 'core' branches: "stable" and "default" (master
and develop in the article)
2. A (named) branch will be created for each feature of bug. Naming
convention: bug-{ticket-number},
feature-{feature-name-or-ticket-number}
3. A (named) branch will be created for each release: release-{release-number}

Feature, bug and release branches may be "closed" once appropriately
merged. Details of movements between branches is detailed in the
article.

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.

NB: once everyone can support push/pull mercurial bookmarks (> v1.6)
we may use bookmarks for some of this.

Further references:

http://forceten.tidalwave.it/development/mercurial-best-practices/
http://www.rabbitmq.com/mercurial.html#branchperbug
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/



More information about the ckan-dev mailing list