couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] Git workflow
Date Thu, 25 Apr 2013 21:11:39 GMT
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