For some reason, Mesos only uses tags, not branches, presumably because we don't want to have to manage merging between a feature/release branches. Everything goes into master, so we tag an rc1 from master, cherry-pick on top of that, then tag an rc2. git checkout 0.1.0-rc1 (checks out the tag, not a branch) git cherry-pick deadbeef facebead ... git tag 0.1.0-rc2 git push --tags
Myriad could certainly do it differently, but we shouldn't be cutting rc's from master after the first one. It should either go into a 0.1.0-rc? set of tags, or a 0.1.x branch. Then a follow-up 0.1.1 could be based on the tag/branch, but a 0.2.0-rc1 would be a new cut from master. On Mon, Nov 30, 2015 at 4:10 PM, Luciano Resende <[email protected]> wrote: > 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/ >
