couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: [DISCUSS] Git workflow
Date Tue, 30 Apr 2013 07:09:07 GMT
On 30 April 2013 01:50, Noah Slater <> wrote:
> 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.

I like this, especially if we can work on extending the CI work Jan +
team have done to all platforms, we can be pretty sure stuff will
"just work".

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

I think we'd push a signed tag that represents 1.4, just as we do
today. This tag is just like a branch head, in that it stays in our
repos indefinitely.

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

I guess it needs to go here, and the branch will only have bugfixes
incorporated. If it's done later, it will include additional
non-breaking features from master, & this branch would be a defacto
1.5 right?

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


View raw message