Nope. I’m proposing making a new 3.x release (as has been discussed in this thread) off today’s trunk (instead of creating a fresh branch-3) and create a new trunk-incompt where incompatible changes that we don’t want in 3.x go.
This is mainly to avoid repeating the “we are not releasing 3.x off trunk” issue when we start thinking about 4.x or any such major release in the future. We’ll do 2.8.x independently and later figure out if 2.9 is needed or not. +Vinod > On Apr 22, 2016, at 5:59 PM, Allen Wittenauer <a...@apache.org> wrote: > > >> On Apr 22, 2016, at 5:38 PM, Vinod Kumar Vavilapalli <vino...@apache.org> >> wrote: >> >> On an unrelated note, offline I was pitching to a bunch of contributors >> another idea to deal with rotting trunk post 3.x: *Make 3.x releases off of >> trunk directly*. >> >> What this gains us is that >> - Trunk is always nearly stable or nearly ready for releases >> - We no longer have some code lying around in some branch (today’s trunk) >> that is not releasable because it gets mixed with other undesirable and >> incompatible changes. >> - This needs to be coupled with more discipline on individual features - >> medium to to large features are always worked upon in branches and get >> merged into trunk (and a nearing release!) when they are ready >> - All incompatible changes go into some sort of a trunk-incompat branch and >> stay there till we accumulate enough of those to warrant another major >> release. >> >> Thoughts? > > Unless I’m missing something, all this proposal does is (using today’s > branch names) effectively rename trunk to trunk-incompat and branch-2 to > trunk. I’m unclear how moving "rotting trunk” to “rotting trunk-incompat” is > really progress. > >
