On 30 April 2013 01:50, Noah Slater <nsla...@apache.org> 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. A+ Dave
