Hi, Yes as my main concern was that the 1.0 release would delay the subsequent release. If we are ready to do RC's now, I find this plan acceptable.
Thank you for working hard to get this rc out. Brock On Tue, Jan 27, 2015 at 12:28 PM, Vikram Dixit K <vikram.di...@gmail.com> wrote: > Hi Folks, > > It has been a few days and I have done all the work needed to produce a 1.0 > RC and think it is better to have a vote on it. I still hope that we can > have this release as 1.0 and Brock's release as 1.1. By the end of the day > I think having more releases is a good thing for the community as is moving > to 1.0 sooner rather than later. > > Thanks > Vikram. > > On Fri, Jan 23, 2015 at 6:12 PM, Sergey Shelukhin <ser...@hortonworks.com> > wrote: > > > 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. > > > > > > -- > Nothing better than when appreciated for hard work. > -Mark >
