I think the way it is done in Hadoop space is better for Hadoop space (and better wrt consistency, us being in the Hadoop space). Because no single company or QA process controls or covers all the changes to the product, and some changes go unseen by every actor, stabilization period is a must...
And anyway enterprise software on trunk model does not cut releases immediately off trunk and ship them. With enterprise software there's lengthy QA, with Hadoop there's lengthy "cutting edge" release. How about we cut 1.0 with stable version 0.14.1, and instead of 0.15 do 2.0, like HBase did? We can maintain 1.0 as maintenance release; with 2.0 we can add new unstable stuff, and also remove all the old paths we don't care about (old Hadoop support, HiveCLI(?), old Java version support) etc. On Fri, Jan 23, 2015 at 11:40 AM, Szehon Ho <sze...@cloudera.com> wrote: > Wherever I've seen in enterprise software, the trunk-based development > model has been the standard where all release branches are cut from trunk > and short-lived. I've never heard of a case where a branch originally > designated for 0.14 (minor release) is cut again to become 1.0 (major > release), and I dont think if you ask anyone they will expect it either. > There was also no announced plan when cutting 0.14 branch that it was > eventually going to be 1.0. As Brock pointed out in the beginning, Hadoop > branch/versioning is the only exception and an anti-pattern, and all the > confusion like why 0.xx has features not in 1.0 would not be there if it > followed this. I would really hate to see the same anti-pattern happen to > Hive, so my vote is also against this. Also this standard release > branching practice has been in Hive throughout its history, you wouldn't > make 0.14 out of 0.13 branch, would you? > > From the stability and long-term support use-cases that is very definitely > > the wrong thing to do - to cram code into a 1.0 release. > > Major release is supposed to be stable. > > > I also don't see how cutting 1.0 from trunk precludes it from stabilizing. > Also I don't think those arguments of 0.14 as most stable that can be > backed up, what constitutes stability? Bug fixes are just one part, in > that case there are always more bug fixes in later Hive versions than > earlier ones, so probably API stability is a more measure-able term and > should be more important to consider. > > Thanks, > Szehon > > > On Fri, Jan 23, 2015 at 10:42 AM, Gopal V <gop...@apache.org> wrote: > > > On 1/23/15, 6:59 AM, Xuefu Zhang wrote: > > > >> While it's true that a release isn't going to include everything from > >> trunk, proposed 1.0 release is branched off 0.14, which was again > branched > >> from trunk long time ago. If you compare the code base, you will see the > >> huge difference. > >> > > > > From the stability and long-term support use-cases that is very > definitely > > the wrong thing to do - to cram code into a 1.0 release. > > > > The "huge difference" is *THE* really worrying red-flag. > > > > Or is the thought behind "everything from trunk" that 1.0 just a number? > > > > 0.14.1 in terms of functionality and stability will be much clearer, > >> meeting the all expectations for a major release. > >> > > > > Just to be clear, when hive-14 was released, it was actually a major > > release. > > > > That branch kicked off in Sept and has been updated since then with a > > known set of critical fixes, giving it pedigree and has already seen > > customer time. > > > > In all this discussion, it doesn't sound like you consider 0.15 to be a > > major release - that gives me no confidence in your approach. > > > > Cheers, > > Gopal > > > > On Thu, Jan 22, 2015 at 3:08 PM, Thejas Nair <the...@hortonworks.com> > >> wrote: > >> > >> On Thu, Jan 22, 2015 at 12:31 PM, Xuefu Zhang <xzh...@cloudera.com> > >>> wrote: > >>> > Hi Thejas/Alan, > >>> > > >>> > From all the argument, I think there was an assumption that the > >>> proposed > >>> > 1.0 release will be imminent and 0.15 will happen far after that. > Based > >>> on > >>> > that assumption, 0.15 will become 1.1, which is greater in scope than > >>> 1.0. > >>> > However, this assumption may not be true. The confusion will be > >>> significant > >>> > if 0.15 is released early as 0.15 before 0.14.1 is released as 1.0. > >>> > >>> Yes, the assumption is that 1.0 will be out very soon, before 0.15 > >>> line is ready, and that 0.15 can become 1.1 . > >>> Do you think that assumption won't hold true ? (In previous emails in > >>> this thread, I talk about reasons why this assumption is reliable). > >>> I agree that it does not make sense to release 1.0 as proposed in this > >>> thread if that does not hold true. > >>> > >>> > Another concern is that, the proposed release of 1.0 is a subset of > of > >>> > Hive's functionality, and for major releases users are expecting > major > >>> > improvement in functionality as well as stability. Mutating from > 0.14.1 > >>> > release seems falling short in that expectation. > >>> > >>> Every release of hive has been a subset of tip of the trunk (we branch > >>> for release while trunk moves ahead), and super set of changes of > >>> every previous release. So every release so far has had a subset of > >>> functionality of hive trunk branch (if that is what you are referring > >>> to). > >>> With the 1.0 proposed based on 0.14 maintenance branch, this still > >>> holds true. (Again, this is with the assumption you called out about > >>> about timeline of 1.0 and 0.15). > >>> > >>> -- > >>> CONFIDENTIALITY NOTICE > >>> NOTICE: This message is intended for the use of the individual or > entity > >>> to > >>> which it is addressed and may contain information that is confidential, > >>> privileged and exempt from disclosure under applicable law. If the > reader > >>> of this message is not the intended recipient, you are hereby notified > >>> that > >>> any printing, copying, dissemination, distribution, disclosure or > >>> forwarding of this communication is strictly prohibited. If you have > >>> received this communication in error, please contact the sender > >>> immediately > >>> and delete it from your system. Thank You. > >>> > >>> > >> > >> > > > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
