Great comments Vinod, thanks for replying. Since trunk is a superset of branch-2.8, I think the two efforts are mostly aligned. The 2.8 blockers are likely also 3.0 blockers. For example, the create-release and L&N JIRAs I mentioned are in this camp. The difference between the two is the expectation as to the level of quality. Once we get create-release and L&N settled, I think it's ready for an alpha. Yes, this means we ship with some known issues, but right now there's no 3.0 artifact for downstreams to compile and test against. Considering that we're shipping incompatible changes, I want to give downstreams as much opportunity to give feedback as possible.
While welcoming the push for alphas, i think we should set some exit > criteria. Otherwise, I can imagine us doing 3/4/5 alpha releases, and then > getting restless about calling it beta or GA of whatever. Essentially, > instead of today’s questions as to "why we aren’t doing a 3.x release", > we’d be fielding a "why is 3.x still considered alpha” question. This > happened with 2.x alpha releases too and it wasn’t fun. > > 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. I think we all have an interest in declaring beta/GA, no one wants eternal alpha releases. 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. > 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? Linux has a "next" branch for separate from master for integrating pending feature branches. I think this is a good model, and would be even better if we published artifacts to assist with testing. However, that depends on someone stepping up to be the maintainer of the integration branch. I really like a more stringent policy around branch merges and new feature development. That'd be great. For 3.x, my strawman was to release off trunk for the alphas, then branch a branch-3 for the beta and onwards. Best, Andrew
