hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lefty Leverenz <leftylever...@gmail.com>
Subject Re: Created branch 1.0
Date Sat, 24 Jan 2015 00:01:57 GMT
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 <szehon@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 <gopalv@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 <thejas@hortonworks.com>
> >> wrote:
> >>
> >>  On Thu, Jan 22, 2015 at 12:31 PM, Xuefu Zhang <xzhang@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.
> >>>
> >>>
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message