[ckan-dev] New branching and repository policy

[David Read]

Rufus,

Thanks for this, although it's probably worth explaining why you propose this.

I like the idea of branch-per-feature for these reasons:
* it is one way to tighten up on badly explained check-ins. This helps
when preparing a release, understanding exactly what is going in.
* the default branch has fewer check-ins of more complete features, so
less likely to break as frequently. Bad check-ins would be easier to
identify and more easily reverted.

The disadvantages are:
* a bit of hassle for developers until they are used to it
* feature branches wouldn't necessarily be on buildbot

So I think this would be most useful with CKAN expanding more and
more, but would ask that we get buildbot to test all open branches in
the repo.

The article also mentions branching for specific releases, which I
like - was that your intention? These would be like our current
metastable branch. Having this would let us 'trial' releases on test
servers easily. I don't mind this would be branch per release or have
a continuous branch as we have now for metastable.

I don't see much advantage of using bookmarks over named branches. You
can rename bookmarks, but the permanence and easy distribution of
branch names seems useful.

I don't see any advantage in each of us push/pulling to a personal
bitbucket if we're working on a feature branch by default. It's not as
easy to autobuild, and the changesets are less visible to the rest of
the team.

David

On 25 November 2010 09:04, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> 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/
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>