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
