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
