Mailing-List: contact dev-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Received-SPF: pass (athena.apache.org: domain of cwsteinbach@gmail.com
 designates 209.85.213.177 as permitted sender)
MIME-Version: 1.0
Date: Wed, 3 Dec 2014 15:43:07 -0800
Message-ID: 
 <CACf6Rrxitxk64O8C8okDAqTCVW1Mhd3TxFfYiWQ438fcODfmmQ@mail.gmail.com>
Subject: Re: Apache Hive 1.0 ?
From: Carl Steinbach <cwsteinbach@gmail.com>
To: "dev@hive.apache.org" <dev@hive.apache.org>
Content-Type: multipart/alternative; boundary=20cf303f6486d352960509586710

--20cf303f6486d352960509586710
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'd like to see HiveCLI, HiveServer, and the original JDBC driver
deprecated and purged from the codebase before the 1.0 release. This topic
probably needs its own thread, but I thought I should mention it here.

Thanks.

- Carl

On Wed, Dec 3, 2014 at 2:27 PM, Enis S=C3=B6ztutar <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).
>
> The important thing for calling something 1.0 I think is the focus on use=
r
> level API and compatibility issues. 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/%3C531153=
41.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 wil=
l
> > 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 lo=
t
> 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 outsid=
er
> 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 th=
e
> > > 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 t=
o
> > > 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 provid=
es
> > > > 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 lik=
e
> 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, 9=
9
> > 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 go=
od
> > > 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 releas=
e
> > 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 Hiv=
e
> > > >> > > obscures this status of Hive.
> > > >> > >
> > > >> > > I propose creating a 1.0 release out of the 0.14 branch of Hiv=
e.
> > 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, an=
d
> 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 yo=
u
> > have
> > > >> > > received this communication in error, please contact the sende=
r
> > > >> > 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 ha=
ve
> > > >> 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 confidentia=
l,
> > > privileged and exempt from disclosure under applicable law. If the
> reader
> > > of this message is not the intended recipient, you are hereby notifie=
d
> > 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.
> > >
> >
>

--20cf303f6486d352960509586710--