couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: [DISCUSS] Git workflow
Date Thu, 25 Apr 2013 20:51:49 GMT
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:

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

On 25 April 2013 21:37, Robert Newson <> 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.


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