Same tag approach works for 0.1.1 too. git checkout 0.1.0 (we'd tag the official 0.1.0 release too) git cherry-pick ... git tag 0.1.1-rc1 git push --tags
Of course, I'm not mandating this, just proposing an option based on how Mesos does it. On Tue, Dec 1, 2015 at 8:59 AM, Darin Johnson <[email protected]> wrote: > I like Adam's idea for RCs, but I also really like the idea of a 0.1.0 > branch for bug fixes. That way we can cut a 0.1.1 maintenance release much > easier than trying to cut off master. Seems like a lot of apache projects > handle it that way. > > Darin > > Otherwise there will likely be some really ugly merges. > On Mon, Nov 30, 2015 at 1:49 PM, Adam Bordelon <[email protected]> wrote: > > > Sounds like a code freeze/thaw. What are the conditions for a *major* PR? > > Even a minor PR could introduce major bugs. > > I will point out that you have the option of cherry-picking specific new > > patches on top of the 0.1.0-rc3 tag to create a new rc. This ensures that > > 0.1.0 only includes changes that were tested in the previous rc's plus > > specific critical fixes. This is how Mesos handles patch releases (e.g. > > 0.23.0 -> 0.23.1) or release candidates after the first. Cut the rc0/1 > from > > HEAD, then cherry-pick on top for all future rcs. > > > > > > > > > Do you mean cherry-pick into branches (e.g. 0.1.x branch) instead of tag > which is supposed to be immutable ? Having a branch also enables future > releases based on 0.1.0 release. > > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ >
