couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: branching in couchdb
Date Wed, 31 Oct 2012 12:21:54 GMT
For my part, I was pretty content with the scheme we agreed to in Dublin
(<jira>-<shortdesc>).

I would like to discuss the old branches that don't follow any scheme at
all, is it time we deleted those?

For going forward, I think every jira-shortdesc branch lives forever. 'git
branch --no-merged master' will show all the branches we haven't merged in,
and I advocate that as our mechanism for figuring out which branches are
dead, rather than removing the sometimes-useful history of a ticket.


On 31 October 2012 09:16, Dave Cottlehuber <dch@jsonified.com> wrote:

> On 31 October 2012 09:07, Benoit Chesneau <bchesneau@gmail.com> wrote:
> > Hello guys,
> >
> > II would like to discuss a little about our branch naming. Today we have
> >  conflicting docs somehow:
> >
> > -
> http://wiki.apache.org/couchdb/Source%20Code%20Repository%20Organization
> >
> > - http://wiki.apache.org/couchdb/ContributorWorkflow
> >
> > and one another I don't find on the wiki now (without my bookmarks)
> >
> >
> > Maybe we can make a one page describing the branching workflow and such ?
> >
> > Also my understanding now is that branch should be named by
> > <TicketNumber>_<shortdescr>
> >
> > which sound good.
> >
> > I would like to introduce another level to help us when we have to look
> on
> > different branches. This is mainly based on that doc :
> >
> >
> http://nxvl.blogspot.fr/2012/07/a-continous-delivery-git-branching-model.html
> >
> > and it could help for continuous integration when we will have it.
> >
> > In short :
> >
> > - a develop branch where all patches should land before to go in master.
> > This branch can be used for final review and make sure it doesn't break
> > anything else.
> >
> > - a `fix/<TicketNumber>_<shortdescr>`  for changes fixing a bug
> > - a `feature/<TicketNumber>_<shortdescr>` for new features
> > - usual X.X.x branch for releases (those we could name them /release/X.X.
> >
> > Thoughts?
> >
> > - benoƮt
>
> +1
>
>
> http://4.bp.blogspot.com/-t4yLz-et74A/UBIES98QPmI/AAAAAAAADGY/S5lwne9xpcM/s1600/releaseFlow.png
>
> seems very similar to the OTP approach as well.
>
> Just tell me what I need to do :-)
>
> A+D
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message