hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vikram Dixit K <vikram.di...@gmail.com>
Subject Re: Created branch 1.0
Date Tue, 27 Jan 2015 20:28:57 GMT
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 <sergey@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 <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.
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
>
> --
> 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

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