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