couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Harvey <d...@arandomurl.com>
Subject Re: [DISCUSS] Git workflow
Date Thu, 25 Apr 2013 21:03:28 GMT
#1 is the procedure almost every project I have worked on follows, we do
actually have an integration branch at mozilla but that is purely due to
the sheer size of the codebase and volume of changes, I see no reason why
CouchDB shouldnt be permanently releasable or why a release would be
'ongoing', it should just be cut at a point in time?

I do question the value of having 4 active releases though


On 25 April 2013 21:51, Noah Slater <nslater@apache.org> wrote:

> Thanks for kicking this off, Bob!
>
> Option 1 would require us to change how we think about master. If a release
> is ongoing (which will almost certainly be the case, month over month) then
> work is going to need to be merged when it is okayed by the release
> manager.
>
> In this scenario, to  we might want to consider some sort of integration
> branch, or "develop" branch that you can merge your feature branches back
> into, while master is being used for release prep.
>
> Option 2 sounds promising, because there is less risk that we're going to
> re-invent the wheel (badly). It might also make it easier to attract
> contributors if we're using a known model.
>
> I'm not a Git pro, so my contributions to this thread are going to be more
> of the "what about X?" nature. I had a look at Gitflow, and I can't readily
> see how maintenance branches would work.
>
> The author suggests that release branches are discarded once you make a
> release. But we need to account for the fact that at any one time, we will
> have 4 active release branches. 1.0.x, 1.1.x, 1.2.x, and 1.3.x, for
> example. We need these to backport fixes, etc.
>
> Further reading:
>
> https://github.com/nvie/gitflow
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
>
>
> http://stackoverflow.com/questions/2621610/what-git-branching-models-actually-work
>
> What are other projects using? Node, for example. Any other big projects
> that use Git. It might be a good idea to borrow from one of these projects,
> especially if there is some established thing that is shared amongst lots
> of them. Sort of how we're using Tom Preston-Werner's semantic versioning!
>
> Hoping somebody with more skin in the game (i.e. doing / or planning to do
> a lot of coding) and more experience of Git (I only learn how to rebase
> recently) decides to run with this and come up with a proposal that we can
> all vote on. Perfect opportunity for someone to do a bit of project
> leadership!
>
>
>
> On 25 April 2013 21:37, Robert Newson <rnewson@apache.org> wrote:
>
> > Hi,
> >
> > We need to agree on how we will use Git effectively to support our new
> > regular release cadence. The motivating questions are how we handle
> > branches during feature releases (a.b.0) and how we handle branches
> > for maintenance releases (a.b.c).
> >
> > I present two options to get this rolling but these are not the only
> > choices, please suggest your own if neither suit.
> >
> > 1.
> >
> > Master is always releasable. All work occurs on feature or fix
> > branches and is merged to master only after tests confirm that it
> > works.
> >
> > A feature release (of form a.b.0) is tagged directly on master. A
> > branch is made from that tag called a.b.x (where x is a literal x)
> >
> > A maintenance release of form (a.b.c) is made on the a.b.x branch and
> > almost always consists of backported or cherry-picked work from
> > master. It is anticipated that some novel work will occur on these
> > branches but only to fix bugs never to add features.
> >
> > 2.
> >
> > Use Gitflow.
> >
> > Other suggestions are welcome and feedback on these is very welcome.
> > Consider this urgent as we need to begin the 1.4.0 release.
> >
> >
> > B.
> >
>
>
>
> --
> NS
>

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