I am with Vinod on avoiding merging mostly_complete_branches to trunk since we are not shipping any release off it. If 3.x releases going off of trunk is going to help with this, I am fine with that approach. We should still make sure to keep trunk-incompat small and not include large features.
On Sat, Apr 23, 2016 at 6:53 PM, Chris Douglas <cdoug...@apache.org> wrote: > If we're not starting branch-3/trunk, what would distinguish it from > trunk/trunk-incompat? Is it the same mechanism with different labels? > > That may be a reasonable strategy when we create branch-3, as a > release branch for beta. Releasing 3.x from trunk will help us figure > out which incompatibilities can be called out in an upgrade guide > (e.g., "new feature X is incompatible with uncommon configuration Y") > and which require code changes (e.g., "data loss upgrading a cluster > with feature X"). Given how long trunk has been unreleased, we need > more data from deployments to triage. How to manage transitions > between major versions will always be case-by-case; consensus on how > we'll address generic incompatible changes is not saving any work. > > Once created, removing functionality from branch-3 (leaving it in > trunk) _because_ nobody volunteers cycles to address urgent > compatibility issues is fair. It's also more workable than asking that > features be committed to a branch that we have no plan to release, > even as alpha. -C > > On Fri, Apr 22, 2016 at 6:50 PM, Vinod Kumar Vavilapalli > <vino...@apache.org> wrote: > > Tx for your replies, Andrew. > > > >>> For exit criteria, how about we time box it? My plan was to do monthly > >> alphas through the summer, leading up to beta in late August / early > Sep. > >> At that point we freeze and stabilize for GA in Nov/Dec. > > > > > > Time-boxing is a reasonable exit-criterion. > > > > > >> In this case, does trunk-incompat essentially become the new trunk? Or > are > >> we treating trunk-incompat as a feature branch, which periodically > merges > >> changes from trunk? > > > > > > It’s the later. Essentially > > - trunk-incompat = trunk + only incompatible changes, periodically kept > up-to-date to trunk > > - trunk is always ready to ship > > - and no compatible code gets left behind > > > > The reason for my proposal like this is to address the tension between > “there is lot of compatible code in trunk that we are not shipping” and > “don’t ship trunk, it has incompatibilities”. With this, we will not have > (compatible) code not getting shipped to users. > > > > Obviously, we can forget about all of my proposal completely if everyone > puts in all compatible code into branch-2 / branch-3 or whatever the main > releasable branch is. This didn’t work in practice, have seen this not > happening prominently during 0.21, and now 3.x. > > > > There is another related issue - "my feature is nearly ready, so I’ll > just merge it into trunk as we don’t release that anyways, but not the > current releasable branch - I’m lazy to fix the last few stability related > issues”. With this, we will (should) get more disciplined, take feature > stability on a branch seriously and merge a feature branch only when it is > truly ready! > > > >> For 3.x, my strawman was to release off trunk for the alphas, then > branch a > >> branch-3 for the beta and onwards. > > > > > > Repeating above, I’m proposing continuing to make GA 3.x releases also > off of trunk! This way only incompatible changes don’t get shipped to users > - by design! Eventually, trunk-incompat will be latest 3.x GA + enough > incompatible code to warrant a 4.x, 5.x etc. > > > > +Vinod >
