couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Stevens (Gmail)" <wickedg...@gmail.com>
Subject Re: [DISCUSS] Git workflow
Date Thu, 25 Apr 2013 21:54:54 GMT
Speaking as someone who's used git-flow in a small-corporate context (and
not as someone who is likely to be contributing overmuch, so huge grains of
salt), I'd like to make a couple of observations:

- Git flow also presumes that the integration branch ("develop" according
to the defaults, though we use "master" for this role at work) is always
releasable with minor effort (ie. cut the release branch, update version
numbers, etc.).  How much this is actually true depends on how diligent the
committers are about only allowing merges to happen when things are
actually ready.
- Git flow has only two permanent branches; integration, and stable (by
default, they call this "master" but we name it "stable").  The stable
branch has the contents of the most recent previous release.  All other
branches are ephemeral or out of the scope of git-flow.
- Git flow has the concept of a "hotfix" branch that uses stable as a
starting point (ie. right now it could be used to create a v1.3.1 were
CouchDB using the setup), but there's no in-tool support for doing anything
about creating a v1.2.2 release.

That said, there's no magic to git-flow, it's just a codified set of
conventions that make it easier to communicate expectations and execute
commands.  Cutting a "support/v1.2.x" branch and making releases from it
when appropriate wouldn't be any more difficult than using any other
release scheme.

Now, for some personal opinion.  My take on things like this is that
without an obvious use-case mismatch, there's very little reason to not use
an off-the-shelf solution (note that the approach outlined at rnewson's
link is compatible with git-flow feature branches).  This lets the team get
back to improving CouchDB, rather than bikeshedding about what feature
branches should be named, etc.

If anyone does decide to investigate git-flow, I recommend the git-flow-avh
fork, as it is more actively maintained than nvie's original repo.

HTH,
Eli



On Thu, Apr 25, 2013 at 2:11 PM, Noah Slater <nslater@apache.org> wrote:

> Dale,
>
> Take a look at the proposed roadmap process and let me know what you think.
>
> http://wiki.apache.org/couchdb/Roadmap_Process
>
>
> On 25 April 2013 22:03, Dale Harvey <dale@arandomurl.com> wrote:
>
> > #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
> > >
> >
>
>
>
> --
> NS
>

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