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 Mon, 29 Apr 2013 23:50:07 GMT
As far as I understand it them, master becomes the place I cut release
candidates from. It is the place that is "ready to ship" at all points.
Which is a slight departure from how we have operated previous.

If you commit a feature to master with breaking changes, then all that
happens it that in the next feature release window, we bump the major point
version. Otherwise it's just a minor point version. Either way, the release
is just master, and all the things that have been merged to it since the
last feature release.

Let's say I cut 1.4 from master. This is point "a". A few months roll by,
and it's time to do another feature release. Except, in this time, somebody
has committed a change with breaking changes. So the new release is 2.0.
This is point "b".

At point "a": we don't need a 1.4.x branch. Not really. Effectively, master
itself is the 1.4.x branch. If we have no bugfixes, then the next release
from master is 1.5, and we will never need a 1.4.1. (Ah, the joys of
semver.)

At point "b": we need a 1.4.x branch! The breaking changes mean that we
might need that 1.4.1 at some point.

So the question is: at what point is the 1.4.x branch created?

Some options:

1) Before the release is made. 1.4.x is branched from master, and then
releases are cut from that. All changes on master have to be copied over to
1.4.x, for as long as we don't introduce breaking changes.

2) After the release is made. The release is cut from master, and then we
branch from the tree-ish of the tag. (Herp derp, just correct my Git-fu if
I am getting things mixed up. Assume I mean the most obvious thing I could
be trying to say.) We still have the problem that all changes on master
have to be copied over to 1.4.x, for as long as we don't introduce breaking
changes.

3) Just in time. We branch 1.4.x from the tree-ish before the breaking
changes landed in master. And we manually cherry-pick bugfixes over to it
as part of the regular bugfix release cycle.

By the way: the question of getting +1s on merges into master is a good
one. But let's focus on the Git workflow for now, and talk about RTC vs CTR
as a separate, focused discussion.


On 29 April 2013 23:06, Robert Newson <rnewson@apache.org> wrote:

> If production branches follow that rule then there will be broken
> commits that won't build. A feature, or fix, will not land atomically,
> but in all its constituent parts. That's the thing we are striving to
> avoid.
>
> Do I misunderstand you?
>
> B.
>
> On 29 April 2013 23:00, Benoit Chesneau <bchesneau@gmail.com> wrote:
> > imo production branches should only be rebased, no merge so you keep
> > the history easier for people asynchronously branching from
> > productions branch. merges can be really difficult to handle along the
> > time when you have a branch that differs a lot.
> >
> > Also this is why the develop branch exist, so people can merge topic
> > branches in it before rebasing  against master.
> >
> > - benoit
> >
> > On Mon, Apr 29, 2013 at 11:45 PM, Robert Newson <rnewson@apache.org>
> wrote:
> >> I like the idea of +1's to merge from topic to production branch.
> >>
> >> B.
> >>
> >> On 29 April 2013 22:23, Dave Cottlehuber <dch@jsonified.com> wrote:
> >>> On 25 April 2013 23:57, Randall Leeds <randall.leeds@gmail.com> wrote:
> >>>> On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson <rnewson@apache.org>
> wrote:
> >>>>>
> >>>>> 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.
> >>>>
> >>>> I disagree.
> >>>>
> >>>> git-bisect is smart enough to remove whole merges before diving into
> >>>> their constituent commits, IIRC, which reduces the possibility of
> >>>> false negatives if there were intermediate commits that had failing
> >>>> tests on the feature branch but the ultimate merge was clean and
> >>>> green. I'm not sure where this notion that bisecting with merge
> >>>> commits is harder comes from.
> >>>
> >>> Possibly from people just getting to grips with dvcs like git. A
> >>> couple of years ago I definitely struggled with understanding
> >>> bisecting with merged branches but I would have less trouble now I
> >>> hope.
> >>>
> >>>> Similarly, backporting a topic branch should look something like:
> >>>>
> >>>>> git checkout -b topic-branch-1.3.x-backport topic-branch
> >>>>> git rebase --onto 1.3.x master
> >>>>
> >>>> This would produce a branch (topic-branch-1.3.x-backport) which
> >>>> contains all the commits on topic-branch since it diverged from
> >>>> master, rebased onto 1.3.x.
> >>>>
> >>>> Reading history with merge commits can also be easier than the
> >>>> alternative FF-only history since there is a --merges option to
> >>>> git-log. This feature can, for instance, show you time line of topic
> >>>> introduction without the clutter of the individual commits that were
> >>>> necessary to produce them.
> >>>>
> >>>> If I am going to argue one way or another I would actually suggest
> >>>> that feature or topic branches always merge with --no-ff.
> >>>
> >>> If it's more than a single commit, then yes this makes sense to me
> >>> too, I wasn't aware there was flag for it.
> >>>
> >>> Re integration branches, it does not strike me as necessary if we can
> >>> collectively ensure we test branches when people are ready to merge
> >>> them. eg my recent screw-up. caveat coder :-(
> >>>
> >>> So perhaps we should get  a +1 from say a couple of reviewers when you
> >>> want to merge something into a production branch. I like the openbsd
> >>> commit messages in this respect, although we could do that in jira
> >>> rather than in the commit. Reasonable?
> >>>
> >>> A+
> >>> Dave
>



-- 
NS

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