We really didn't define 1.0 very well. The way HBase did this (correct me if I'm wrong) is that 1.0 was the stable release (stable APIs and code). Then 1.1, 1.2 etc. become patch releases, and 2.0 becomes the release for all the new crazy stuff...
On Fri, Jan 23, 2015 at 4:01 PM, Lefty Leverenz <leftylever...@gmail.com> wrote: > Setting aside branching specifics for a moment, what are the pros & cons of > doing release 1.0 now or later? > > - From a documentation point of view, planning a later 1.0 release could > give us time to catch up on the backlog of doc tasks, or at least > prioritize the backlog and address the most important tasks. > - On the other hand, releasing 1.0 sooner *might* increase the pressure > to bring documentation up to par. (Italics added by my inner cynic.) > > What else is at stake here? > > > > -- Lefty > > 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.
