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:54:27 GMT
On 25 April 2013 22:35, Robert Newson <rnewson@apache.org> wrote:

> I'll toss this in too: https://sandofsky.com/blog/git-workflow.html
>
> In particular;
>
> "If you treat your public history as pristine, fast-forward merges are
> not only safe but preferable. They keep revision history linear and
> easier to follow"
>
> I think this also addresses Paul's objections to merge commits (well,
> non-ff merge commits).
>
> If we enhance the #1 proposal to include a final rebase against master
> before merge, then master will be truly linear. That will make for
> easier reading, easier backporting and will enable bisecting when
> spelunking for regressions, etc.
>
> B.
>
>
Very much agreed


>
>
>
> On 25 April 2013 22:11, 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
> >
> >
>

The Roadmap looks good, I would worry that the point of semver is that you
dont need
to support 1.0.X / 1.1.X / 1.2.X and 1.3.X as they are all guaranteed to be
forward
compatible and extended support / backports are for backporting bugfixes to
major version
changes, the release procedure is a slow process and it seems like having 4
active versions
is also confusing for users, but my experience may be differing
requirements.


> > 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