hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brock Noland <br...@cloudera.com>
Subject Re: Apache Hive 1.0 ?
Date Thu, 04 Dec 2014 07:48:56 GMT
On Wed, Dec 3, 2014 at 2:27 PM, Enis Söztutar <enis@apache.org> wrote:

> Hi,
>
> I am the RM for HBase-1.0 coming in a a couple of weeks (hopefully). I
> think both HBase and Hive are past due for doing 1.0 releases. So I am a
> major +1 for Hive-1.0 (non-binding of course).
>

Agreed :)

>
> The important thing for calling something 1.0 I think is the focus on user
> level API and compatibility issues.


I think we need to remember that not all our users write SQL statements.
For example Drill, Spark SQL, PrestoDB, Impala, Kylin, Ranger, Sentry,
Carl's view project at LI, and more are all users of Hive as well. At the
user meetup tonight Carl suggest we get our act together in regards to
documenting which API's are public or not, for these users. I think that
makes a lot of sense.


> But still, you should think about
> future releases and for example when you can do a 1.x release versus 2.x
> release. We have started thinking about that some time ago, and we are
> adopting a semantic versioning proposal (
>
> https://mail-archives.apache.org/mod_mbox/hbase-dev/201411.mbox/%3C53115341.900549.1416100552603.JavaMail.yahoo@jws106116.mail.bf1.yahoo.com%3E
> )
> for this exact same reason. In Hive, things may be a bit different than
> HBase or Hadoop (since the major interface is SQL) but still I think you
> should consider the implications for all the APIs that Hive surfaces and
> for deployment, etc for a 1.0 discussion.
>
> For HBase, the official "theme" of the 1.0 release is (from my RC mail):
> > The theme of (eventual) 1.0 release is to
> > become a stable base for future 1.x series of releases. 1.0 release will
> > aim to achieve at least the same level of stability of 0.98 releases
> > without introducing too many new features.
>
> What I am getting at is that, in HBase, we opted for not introducing a lot
> of major features and branched relatively early to give more time to
> stabilize the branch. In the end what you want to deliver and market as 1.0
> should be relatively stable in my opinion. Just my 2 cents from an outsider
> perspective.
>
> Enis
>
> On Tue, Dec 2, 2014 at 11:07 PM, Lefty Leverenz <leftyleverenz@gmail.com>
> wrote:
>
> > Would everyone just laugh if I suggested that a 1.0 release ought to
> > include complete documentation?
> >
> >
> > -- Lefty
> >
> > On Tue, Dec 2, 2014 at 9:32 PM, Thejas Nair <thejas@hortonworks.com>
> > wrote:
> >
> > > The reasons for confusion in the Hadoop case were different. There
> > > were many branches, and new features were added in minor version
> > > releases, eg kerberos security was not there in "0.20.2", but it was
> > > added in "0.20.20x".  Then you had other versions like "0.21", but the
> > > older "0.20.20x" version was the one that was converted as 1.x.
> > >
> > > This confusion isn't there in hive. In case of hive, every "0.x"
> > > release has been adding new features, and releases have been
> > > sequential. "0.x.y" releases have been maintenance releases. 1.0 is a
> > > sequential release after 0.14, and it is a newer release than 0.14. I
> > > agree that the version in Hadoop created lot of confusion, but I don't
> > > see this as being the same. We could check in the user mailing list to
> > > see if they are going to be HUGELY confused by this.
> > >
> > > If it makes things better, we can also include the change to delete
> > > HiveServer1 in the new release. That is a safer change, which was
> > > mainly just deleting that old code. That would be a major difference
> > > from 0.14. (The docs have already been updated to say that 0.14 does
> > > not support 0.20, so I don't think we need that in 1.0).
> > >
> > > Looks like we have agreement that 1.0 versioning scheme is a great
> > > thing for hive. I don't think there is a strong reason to delay a 1.0
> > > release by several months to the detriment of hive.
> > >
> > >
> > > On Tue, Dec 2, 2014 at 8:05 PM, Xuefu Zhang <xzhang@cloudera.com>
> wrote:
> > > > Major release means more functionality, while minor releases provides
> > > > stability. Therefore, I'd think, 1.0, as a major release, should
> bring
> > in
> > > > something new to the user. If it's desirable to provide more stable
> > > > release, then 0.14.1, 0.14.2, and so on are the right ones. In my
> > > opinion,
> > > > we should avoid doing anti-pattern by introducing major release like
> a
> > > > maintenance release and creating confusions among users.
> > > >
> > > > In one word, major release is NOT equal to major confusion.
> > > >
> > > > --Xuefu
> > > >
> > > > On Tue, Dec 2, 2014 at 7:29 PM, Sergey Shelukhin <
> > sergey@hortonworks.com
> > > >
> > > > wrote:
> > > >
> > > >> I think it's better to do 1.0 release off a maintenance release,
> since
> > > that
> > > >> is more stable. Trunk is moving fast.
> > > >> HBase uses odd release numbers for this purpose, where 0.95, 97, 99
> > etc.
> > > >> are dev releases and 0.96, 0.98, 1.0 etc. are public; that works
> well
> > > for
> > > >> baking, but since we don't have that seems like 14.0 would be a good
> > > place
> > > >> to bake. 15.0 with bunch of new bugs that we are busy introducing
> may
> > > not
> > > >> be as good for 1.0 IMHO...
> > > >>
> > > >> On Tue, Dec 2, 2014 at 7:21 PM, Brock Noland <brock@cloudera.com>
> > > wrote:
> > > >>
> > > >> > Hi Thejas,
> > > >> >
> > > >> > Thank you very much for your proposal!
> > > >> >
> > > >> > Hadoop did something similar renaming branches to branch-1 and
> > > >> > branch-2. At the time, although I was very much in favor of the
> new
> > > >> > release numbers, I thought it could have been handled better.
> > Renaming
> > > >> > release branches ended up being very confusing for users and
I
> had a
> > > >> > ton of conversations with users about how releases were related.
> > > >> >
> > > >> > In this situation, I feel the situation is similar, we'll release
> > 1.0
> > > >> > which is really just the second maintainence release of the 0.14
> > > >> > branch. Thus it's 1.0 but really it's just 0.14 + some fixes.
I
> feel
> > > >> > this will again be confusing for users. For this important
> change, I
> > > >> > think we should use a new release vehicle.
> > > >> >
> > > >> > Thus, I'd suggest we do the rename in trunk, soon, and then the
> next
> > > >> > release of Hive will be 1.0.
> > > >> >
> > > >> > Cheers,
> > > >> > Brock
> > > >> >
> > > >> > On Tue, Dec 2, 2014 at 10:07 AM, Thejas Nair <
> > thejas@hortonworks.com>
> > > >> > wrote:
> > > >> > > Apache Hive is the de facto SQL query engine in the hadoop
> > > ecosystem.
> > > >> > > I believe it is also the most widely used one as well. Hive
is
> > used
> > > in
> > > >> > > production in large number of enterprises.
> > > >> > > However, this 0.x.y versioning that we have been using for
Hive
> > > >> > > obscures this status of Hive.
> > > >> > >
> > > >> > > I propose creating a 1.0 release out of the 0.14 branch
of Hive.
> > We
> > > >> > > already have some bug fixes for 0.14 release that have been
> added
> > to
> > > >> > > the branch and a maintenance release is due. Having it out
of
> this
> > > >> > > maintenance branch would create a better first 1.0 version,
and
> we
> > > >> > > would be able to do it soon. What would have been 0.15 version
> > would
> > > >> > > then become 1.1 version .
> > > >> > >
> > > >> > > Thoughts ?
> > > >> > >
> > > >> > > Thanks,
> > > >> > > Thejas
> > > >> > >
> > > >> > > --
> > > >> > > 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.
> > > >>
> > >
> > > --
> > > 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