As things currently stand, I'm -1 (binding) any new features other than namespaces in 0.96.x.
I think we can all agree that 0.96 has taken way too long to get out. 0.96 will be a monster release with bunches of new features, tons of new code paths, and lots of uncertainty. To combat that lots of people and companies have put tons of effort into testing and stabilizing the current 0.95 branch. The best way I see forward is to start releasing much faster. I'd like to propose: * we stabilize 0.95 branch completely. Make that branch rock solid. * When we are happy with it, release it as 1.0.0. * Then (a couple of months) after release 1.1.0 with hfile v3 and any other feature that haven't made the cut for 1.0.0 . * really start using semver(http://semver.org/) so that users can know for sure that a patch version doesn't bring much risk at all. That will make sure that any new features contributed aren't stuck waiting to be released forever, and we will always be able to have a very stable patch version that risk adverse people can use. Additionally having faster minor release trains will mean that we can be much more rigid in our back-porting policies. On Mon, Jul 29, 2013 at 9:11 PM, Andrew Purtell <apurt...@apache.org> wrote: > On Mon, Jul 29, 2013 at 8:44 PM, Stack <st...@duboce.net> wrote: > >> > Would we be able to get an HFile V3 into 0.96.1 if 0.96.0 goes out >> without? >> >> It'd be a feature I suppose? 0.98? What you thinking Andrew? >> > > Waiting for tags in 0.98 would not be good because we have dependent issues > that would have to wait too. If 0.96.1 instead of 0.96.0 is doable for the > file format we can focus on API changes for 0.96.0 that are a must and so > narrow the scope under consideration today. > >> Redo what ye have but it'll take too long? Could ye get core parts in? > > We are addressing feedback. Updated patch on RB forthcoming. > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White)
