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. >>> >>> >> >> >
