On 30 April 2013 08:09, Dave Cottlehuber <[email protected]> wrote: > On 30 April 2013 01:50, Noah Slater <[email protected]> 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".
Yep. Ideally, we'll agree on a process to make sure tests are passing *before* the merge. This is a separate discussion, however! > > 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. Yep, sorry. I took that as a given. > > 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? > Bingo. -- NS
