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/
