You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by Edward Capriolo <ed...@gmail.com> on 2015/02/09 17:38:48 UTC
Re: Created branch 1.0
Question.
https://issues.apache.org/jira/browse/HIVE-8614
Did we not just agree in this thread that hive will no long have dependency
that are SNAPSHOT?
On Fri, Jan 23, 2015 at 1:06 AM, Brock Noland <br...@cloudera.com> wrote:
> Hi Alan,
>
> I agree with Xuefu and what was suggested in your statement. I was
> thinking we'd release the next release as 0.15 and then later there
> would be 1.0 off trunk (e.g. what would have been 0.16) and thus be
> superset (minus anything we intentionally remove).
>
> As I have said several times, I'd like to release more often so I feel
> we could even start the 1.0 work shortly after the 0.15 release. For
> my part, I do agree with some earlier contributor/user sentiment that
> it would be good to have some basic public API defined for 1.0. I
> don't think that will be too hard as it's more or less obvious what
> our public API is today.
>
> Hope this seems reasonable.
>
> Cheers,
> Brock
>
> On Thu, Jan 22, 2015 at 2:31 PM, Xuefu Zhang <xz...@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.
> >
> > 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.
> >
> > Having said that, I'd think it makes more sense to release 0.15 as 0.15,
> > and later we release 1.0 as the major release that supersedes any
> previous
> > releases. That will fulfill the expectations of a major release.
> >
> > Thanks,
> > Xuefu
> >
> > On Thu, Jan 22, 2015 at 12:12 PM, Alan Gates <ga...@hortonworks.com>
> wrote:
> >
> >> I had one clarifying question for Brock and Xuefu. Was your proposal to
> >> still call the branch from trunk you are planning in a few days 0.15
> (and
> >> hence release it as 0.15) and have 1.0 be a later release? Or did you
> want
> >> to call what is now 0.15 1.0? If you wanted 1.0 to be post 0.15, are
> you
> >> ok with stipulating that the next release from trunk after 0.15 (what
> would
> >> have been 0.16) is 1.0?
> >>
> >> Alan.
> >>
> >> Thejas Nair <th...@hortonworks.com>
> >> January 22, 2015 at 12:04
> >> Brock, Xuefu,
> >>
> >> We seem to have trouble reaching to a consensus here. (Please see my
> >> arguments why I don't see this causing confusions, and let me know if
> >> it changes your opinion).
> >> How should we move forward ? Do you think we need to go through a
> >> formal vote regarding the release plan as per hive by-laws ?
> >>
> >>
> >> Thejas Nair <th...@hortonworks.com>
> >> January 22, 2015 at 10:38
> >> I don't see any reasons for confusion.
> >> From a user perspective, 1.0 is going to have a super set of changes of
> >> 0.14.
> >> 1.1 (based on planned 0.15 release) will have a super set of changes in
> >> 1.0 .
> >>
> >>
> >> Xuefu Zhang <xz...@cloudera.com>
> >> January 21, 2015 at 22:47
> >> I strongly believe that the concept of 1.0 out of a branch as proposed
> is
> >> creating the greatest confusion in the community. If for any reason that
> >> 1.0 cannot be cut from the trunk, that means that we are not ready and
> so
> >> shall wait until so before considering such a release. Thus, I'd -1 on
> this
> >> proposal.
> >>
> >> Thanks,
> >> Xuefu
> >>
> >>
> >> Gopal V <go...@apache.org>
> >> January 21, 2015 at 22:29
> >> On 1/21/15, 7:09 PM, Brock Noland wrote:
> >>
> >> Too be clear I strongly feel creating 1.0 from 0.14 will be confusing.
> In
> >> fact it's already crrated confusion amongst folks on this list.
> >> Furthermore
> >> 1.0 should be created from trunk and be a superset of previous releases.
> >>
> >>
> >> I don't think there is any confusion over that - 1.0 is a long-term
> >> maintenance which is going to be a super-set of all *critical fixes*
> made
> >> from here on (emphasis).
> >>
> >> In fact, a long-term support release should be released off an actively
> >> updated maintenance branch, which has been baked-in and never from the
> >> trunk.
> >>
> >> Those who have followed the earlier mails would realize that the most
> >> important "feature" about this branch is to stick to only long term
> >> maintenance - which in effect is adopting HBase's successful idea.
> >>
> >> That is just plain solid engineering.
> >>
> >> Anyway, it would be in the best interests of the larger community, to
> find
> >> out who else finds that approach confusing.
> >>
> >> Brock, I'm not sure whether you are confused or whether you think other
> >> people will be confused (and if so, why?).
> >>
> >> Cheers,
> >> Gopal
> >>
> >> On Wed, Jan 21, 2015 at 6:05 PM, Vikram Dixit K <vikram.dixit@gmail.com
> >
> >> <vi...@gmail.com>
> >> wrote:
> >>
> >> @Brock,
> >>
> >> I created this branch from 0.14. I created this branch based on the
> email
> >> thread discussing 1.0,
> >>
> >> http://search-hadoop.com/m/8er9YGX8g2
> >>
> >> where you had said you agreed with the suggestion from Enis from HBase
> who
> >> said that we should base 1.0 on a stable version rather than making it a
> >> feature release.
> >>
> >> @Lefty,
> >>
> >> You are right in that branch 0.14 has been made 1.0. You are also right
> >> that 0.15 would be 1.1.0 and we should capture that.
> >>
> >> Regards
> >> Vikram.
> >>
> >> On Wed, Jan 21, 2015 at 5:13 PM, Thejas Nair <th...@hortonworks.com>
> >> <th...@hortonworks.com>
> >>
> >> wrote:
> >>
> >>
> >> Hi Lefty,
> >> Yes, you are right. Anything that is not fixed in 0.14 and is fixed in
> >> 1.0 would have 1.0 as the fixed version.
> >> Yes, 0.15.0 would then become 1.1.0 .
> >>
> >> Yes, it is a good idea to document this translation somewhere.
> >>
> >>
> >> On Wed, Jan 21, 2015 at 3:28 PM, Lefty Leverenz <
> leftyleverenz@gmail.com>
> >> <le...@gmail.com>
> >> wrote:
> >> > So my initial impression was correct -- instead of calling it release
> >> > 0.14.1, we're calling it 1.0.0. Or am I hopelessly confused?
> >> >
> >> > Will 0.15.0 be 1.1.0? (If so, I'll need to edit a dozen wikidocs.)
> >> >
> >> > Will release numbers get changed in JIRA issues? Presumably that's not
> >> > possible in old comments, so we should document the equivalences
> >> > somewhere. A JIRA issue for that with a well-phrased summary could
> help
> >> > future searchers.
> >> >
> >> >
> >> > -- Lefty
> >> >
> >> > On Wed, Jan 21, 2015 at 2:47 PM, Eugene Koifman <
> >> ekoifman@hortonworks.com>
> >> > wrote:
> >> >
> >> >> could we include HIVE-9390 & HIVE-9404? This has been committed to
> >> trunk.
> >> >> They add useful retry logic to support insert/update/delete
> >> functionality.
> >> >>
> >> >> On Wed, Jan 21, 2015 at 1:06 PM, Vikram Dixit K <
> >>
> >> vikram.dixit@gmail.com
> >>
> >> >
> >> >> wrote:
> >> >>
> >> >> > Hi Folks,
> >> >> >
> >> >> > I have created branch 1.0 as discussed earlier. All the jiras that
> >> have
> >> >> > 0.14 as the fix version should be committed to 1.0 branch instead.
> >>
> >> The
> >>
> >> >> list
> >> >> > of jiras that are being tracked for 1.0 are as follows:
> >> >> >
> >> >> > HIVE-8485
> >> >> > HIVE-9053
> >> >> > HIVE-8996.
> >> >> >
> >> >> > Please let me know if you want to include more jiras here. I am
> >> working
> >> >> on
> >> >> > generating javadocs for this. I hope to have an RC out once these
> >> jiras
> >> >> get
> >> >> > in.
> >> >> >
> >> >> > Regards
> >> >> > Vikram.
> >> >> >
> >> >> > On Tue, Jan 20, 2015 at 1:00 PM, Vaibhav Gumashta <
> >> >> > vgumashta@hortonworks.com
> >> >> > > wrote:
> >> >> >
> >> >> > > Hi Vikram,
> >> >> > >
> >> >> > > I'd like to get this in: HIVE-8890
> >> >> > > <https://issues.apache.org/jira/browse/HIVE-8890>
> >> <https://issues.apache.org/jira/browse/HIVE-8890> [HiveServer2
> >> dynamic
> >> >> > > service discovery: use persistent ephemeral nodes curator
> recipe].
> >> >> > >
> >> >> > > Thanks,
> >> >> > > --Vaibhav
> >> >> > >
> >> >> > > On Mon, Jan 19, 2015 at 9:29 PM, Alan Gates <
> gates@hortonworks.com
> >>
> >>
> >> >> > wrote:
> >> >> > >
> >> >> > > > I'd really like to get HIVE-8966 in there, since it breaks
> >> streaming
> >> >> > > > ingest. The patch is ready to go, it's just waiting on a
> >>
> >> review,
> >>
> >> >> which
> >> >> > > > Owen has promised to do soon.
> >> >> > > >
> >> >> > > > Alan.
> >> >> > > >
> >> >> > > > Vikram Dixit K <vi...@gmail.com> <
> vikram.dixit@gmail.com>
> >> >> > > > January 19, 2015 at 18:53
> >> >> > > > Hi All,
> >> >> > > >
> >> >> > > > I am going to be creating the branch 1.0 as mentioned earlier,
> >> >> > tomorrow.
> >> >> > > I
> >> >> > > > have the following list of jiras that I want to get committed
> >>
> >> to
> >>
> >> the
> >> >> > > branch
> >> >> > > > before creating an RC.
> >> >> > > >
> >> >> > > > HIVE-9112
> >> >> > > > HIVE-6997 : Delete hive server 1
> >> >> > > > HIVE-8485
> >> >> > > > HIVE-9053
> >> >> > > >
> >> >> > > > Please let me know if you would like me to include any other
> >> jiras.
> >> >> > > >
> >> >> > > > Thanks
> >> >> > > > Vikram.
> >> >> > > >
> >> >> > > >
> >> >> > > > On Fri, Jan 16, 2015 at 1:35 PM, Vikram Dixit K <
> >> >> > vikram.dixit@gmail.com>
> >> >> > > > <vi...@gmail.com> <vi...@gmail.com>
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > > > Thejas Nair <th...@hortonworks.com> <th...@hortonworks.com>
> >> >> > > > January 1, 2015 at 10:23
> >> >> > > > Yes, 1.0 is a good opportunity to remove some of the deprecated
> >> >> > > > components. The change to remove HiveServer1 is already there
> >>
> >> in
> >>
> >> >> trunk
> >> >> > > > , we should include that.
> >> >> > > > We can also use 1.0 release to clarify the public vs private
> >> status
> >> >> of
> >> >> > > > some of the APIs.
> >> >> > > >
> >> >> > > > Thanks for the reminder about the documentation status of
> >>
> >> 1.0. I
> >>
> >> will
> >> >> > > > look at some of them.
> >> >> > > >
> >> >> > > >
> >> >> > > > On Wed, Dec 31, 2014 at 12:12 AM, Lefty Leverenz
> >> >> > > >
> >> >> > > > Lefty Leverenz <le...@gmail.com>
> >> <le...@gmail.com>
> >> >> > > > December 31, 2014 at 0:12
> >> >> > > > Oh, now I get it. The 1.0.0 *branch* of Hive. Okay.
> >> >> > > >
> >> >> > > > -- Lefty
> >> >> > > >
> >> >> > > > On Tue, Dec 30, 2014 at 11:43 PM, Lefty Leverenz <
> >> >> > > leftyleverenz@gmail.com>
> >> >> > > > <le...@gmail.com> <le...@gmail.com>
> >> >> > > >
> >> >> > > > Lefty Leverenz <le...@gmail.com>
> >> <le...@gmail.com>
> >> >> > > > December 30, 2014 at 23:43
> >> >> > > > I thought x.x.# releases were just for fixups, x.#.x could
> >>
> >> include
> >>
> >> >> new
> >> >> > > > features, and #.x.x were major releases that might have some
> >> >> > > > backward-incompatible changes. But I guess we haven't agreed
> >>
> >> on
> >>
> >> that.
> >> >> > > >
> >> >> > > > As for documentation, we still have 84 jiras with TODOC14
> >>
> >> labels
> >>
> >> >> > > >
> >> >> > > > <
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC14
> >>
> >> >> > > >
> >> >> > > > <
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC14
> >>
> >> >> > > >
> >> >> > > > .
> >> >> > > > Not to mention 25 TODOC13 labels
> >> >> > > >
> >> >> > > > <
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC13
> >>
> >> >> > > >
> >> >> > > > <
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC13
> >>
> >> >> > > >
> >> >> > > > ,
> >> >> > > > eleven TODOC12
> >> >> > > >
> >> >> > > > <
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC12
> >>
> >> >> > > >
> >> >> > > > <
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC12
> >>
> >> >> > > >
> >> >> > > > ,
> >> >> > > > seven TODOC11
> >> >> > > >
> >> >> > > > <
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC11
> >>
> >> >> > > >
> >> >> > > > <
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC11
> >>
> >> >> > > >
> >> >> > > > ,
> >> >> > > > and seven TODOC10
> >> >> > > >
> >> >> > > > <
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC10
> >>
> >> >> > > >
> >> >> > > > <
> >> >> > >
> >> >> >
> >> >>
> >>
> >>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC10
> >>
> >> >> > > >
> >> >> > > > .
> >> >> > > >
> >> >> > > > That's 134 doc tasks to finish for a Hive 1.0.0 release --
> >> preferably
> >> >> > by
> >> >> > > > the release date, not after. Because expectations are higher
> >>
> >> for
> >>
> >> >> 1.0.0
> >> >> > > > releases.
> >> >> > > >
> >> >> > > >
> >> >> > > > -- Lefty
> >> >> > > >
> >> >> > > > On Tue, Dec 30, 2014 at 5:23 PM, Vikram Dixit K <
> >> >> > vikram.dixit@gmail.com>
> >> >> > > > <vi...@gmail.com> <vi...@gmail.com>
> >> >> > > >
> >> >> > > > Vikram Dixit K <vi...@gmail.com> <
> vikram.dixit@gmail.com>
> >> >> > > > December 30, 2014 at 17:23
> >> >> > > > Hi Folks,
> >> >> > > >
> >> >> > > > Given that there have been a number of fixes that have gone
> >>
> >> into
> >>
> >> >> branch
> >> >> > > > 0.14 in the past 8 weeks, I would like to make a release
> >>
> >> of
> >> 0.14.1
> >>
> >> >> > soon.
> >> >> > > I
> >> >> > > > would like to fix some of the release issues as well this
> >>
> >> time
> >>
> >> >> around.
> >> >> > I
> >> >> > > am
> >> >> > > > thinking of some time around 15th January for getting a RC
> >>
> >> out.
> >>
> >> >> Please
> >> >> > > let
> >> >> > > > me know if you have any concerns. Also, from a previous thread,
> >>
> >> I
> >>
> >> >> would
> >> >> > > > like to make this release the 1.0 branch of hive. The process
> >>
> >> for
> >>
> >> >> > getting
> >> >> > > > jiras into this release is going to be the same as the previous
> >> one
> >> >> > viz.:
> >> >> > > >
> >> >> > > > 1. Mark the jira with fix version 0.14.1 and update the status
> >>
> >> to
> >>
> >> >> > > > blocker/critical.
> >> >> > > > 2. If a committer +1s the patch for 0.14.1, it is good to
> >>
> >> go in.
> >>
> >> >> Please
> >> >> > > > mention me in the jira in case you are not sure if the jira
> >>
> >> should
> >>
> >> >> make
> >> >> > > it
> >> >> > > > for 0.14.1.
> >> >> > > >
> >> >> > > > Thanks
> >> >> > > > Vikram.
> >> >> > > >
> >> >> > > >
> >> >> > > > 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
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Thanks,
> >> >> Eugene
> >> >>
> >> >> --
> >> >> 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
> >>
> >>
> >>
> >>
> >>
> >> 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.
> >>
>
Re: Created branch 1.0
Posted by Vikram Dixit K <vi...@gmail.com>.
The build check in HIVE-8933 fixed in HIVE-8845.
On Mon, Feb 9, 2015 at 11:32 AM, Vikram Dixit K <vi...@gmail.com>
wrote:
> Hi Ed,
>
> This was the case with 0.14. It was fixed before 1.0 went out in HIVE-8933.
>
> Thanks
> Vikram.
>
> On Mon, Feb 9, 2015 at 9:08 AM, Alan Gates <al...@gmail.com> wrote:
>
>> That's fixed, correct? I do not believe there were any SNAPSHOT
>> dependencies in 1.0.
>>
>> Alan.
>>
>> Edward Capriolo <ed...@gmail.com>
>> February 9, 2015 at 8:40
>> Because we can not really have a stable api if by definition we build
>> around snapshot dependencies.
>>
>> On Mon, Feb 9, 2015 at 11:38 AM, Edward Capriolo <ed...@gmail.com>
>> <ed...@gmail.com>
>>
>> Edward Capriolo <ed...@gmail.com>
>> February 9, 2015 at 8:38
>> Question.
>>
>> https://issues.apache.org/jira/browse/HIVE-8614
>>
>> Did we not just agree in this thread that hive will no long have
>> dependency
>> that are SNAPSHOT?
>>
>>
>> Brock Noland <br...@cloudera.com>
>> January 22, 2015 at 22:06
>> Hi Alan,
>>
>> I agree with Xuefu and what was suggested in your statement. I was
>> thinking we'd release the next release as 0.15 and then later there
>> would be 1.0 off trunk (e.g. what would have been 0.16) and thus be
>> superset (minus anything we intentionally remove).
>>
>> As I have said several times, I'd like to release more often so I feel
>> we could even start the 1.0 work shortly after the 0.15 release. For
>> my part, I do agree with some earlier contributor/user sentiment that
>> it would be good to have some basic public API defined for 1.0. I
>> don't think that will be too hard as it's more or less obvious what
>> our public API is today.
>>
>> Hope this seems reasonable.
>>
>> Cheers,
>> Brock
>> Xuefu Zhang <xz...@cloudera.com>
>> January 22, 2015 at 12:31
>> 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.
>>
>> 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.
>>
>> Having said that, I'd think it makes more sense to release 0.15 as 0.15,
>> and later we release 1.0 as the major release that supersedes any previous
>> releases. That will fulfill the expectations of a major release.
>>
>> Thanks,
>> Xuefu
>>
>>
>> Alan Gates <ga...@hortonworks.com>
>> January 22, 2015 at 12:12
>> I had one clarifying question for Brock and Xuefu. Was your proposal to
>> still call the branch from trunk you are planning in a few days 0.15 (and
>> hence release it as 0.15) and have 1.0 be a later release? Or did you want
>> to call what is now 0.15 1.0? If you wanted 1.0 to be post 0.15, are you
>> ok with stipulating that the next release from trunk after 0.15 (what would
>> have been 0.16) is 1.0?
>>
>> Alan.
>>
>>
>
>
> --
> Nothing better than when appreciated for hard work.
> -Mark
>
--
Nothing better than when appreciated for hard work.
-Mark
Re: Created branch 1.0
Posted by Vikram Dixit K <vi...@gmail.com>.
Hi Ed,
This was the case with 0.14. It was fixed before 1.0 went out in HIVE-8933.
Thanks
Vikram.
On Mon, Feb 9, 2015 at 9:08 AM, Alan Gates <al...@gmail.com> wrote:
> That's fixed, correct? I do not believe there were any SNAPSHOT
> dependencies in 1.0.
>
> Alan.
>
> Edward Capriolo <ed...@gmail.com>
> February 9, 2015 at 8:40
> Because we can not really have a stable api if by definition we build
> around snapshot dependencies.
>
> On Mon, Feb 9, 2015 at 11:38 AM, Edward Capriolo <ed...@gmail.com>
> <ed...@gmail.com>
>
> Edward Capriolo <ed...@gmail.com>
> February 9, 2015 at 8:38
> Question.
>
> https://issues.apache.org/jira/browse/HIVE-8614
>
> Did we not just agree in this thread that hive will no long have dependency
> that are SNAPSHOT?
>
>
> Brock Noland <br...@cloudera.com>
> January 22, 2015 at 22:06
> Hi Alan,
>
> I agree with Xuefu and what was suggested in your statement. I was
> thinking we'd release the next release as 0.15 and then later there
> would be 1.0 off trunk (e.g. what would have been 0.16) and thus be
> superset (minus anything we intentionally remove).
>
> As I have said several times, I'd like to release more often so I feel
> we could even start the 1.0 work shortly after the 0.15 release. For
> my part, I do agree with some earlier contributor/user sentiment that
> it would be good to have some basic public API defined for 1.0. I
> don't think that will be too hard as it's more or less obvious what
> our public API is today.
>
> Hope this seems reasonable.
>
> Cheers,
> Brock
> Xuefu Zhang <xz...@cloudera.com>
> January 22, 2015 at 12:31
> 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.
>
> 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.
>
> Having said that, I'd think it makes more sense to release 0.15 as 0.15,
> and later we release 1.0 as the major release that supersedes any previous
> releases. That will fulfill the expectations of a major release.
>
> Thanks,
> Xuefu
>
>
> Alan Gates <ga...@hortonworks.com>
> January 22, 2015 at 12:12
> I had one clarifying question for Brock and Xuefu. Was your proposal to
> still call the branch from trunk you are planning in a few days 0.15 (and
> hence release it as 0.15) and have 1.0 be a later release? Or did you want
> to call what is now 0.15 1.0? If you wanted 1.0 to be post 0.15, are you
> ok with stipulating that the next release from trunk after 0.15 (what would
> have been 0.16) is 1.0?
>
> Alan.
>
>
--
Nothing better than when appreciated for hard work.
-Mark
Re: Created branch 1.0
Posted by Alan Gates <al...@gmail.com>.
That's fixed, correct? I do not believe there were any SNAPSHOT
dependencies in 1.0.
Alan.
> Edward Capriolo <ma...@gmail.com>
> February 9, 2015 at 8:40
> Because we can not really have a stable api if by definition we build
> around snapshot dependencies.
>
> On Mon, Feb 9, 2015 at 11:38 AM, Edward Capriolo <ed...@gmail.com>
>
> Edward Capriolo <ma...@gmail.com>
> February 9, 2015 at 8:38
> Question.
>
> https://issues.apache.org/jira/browse/HIVE-8614
>
> Did we not just agree in this thread that hive will no long have
> dependency
> that are SNAPSHOT?
>
>
> Brock Noland <ma...@cloudera.com>
> January 22, 2015 at 22:06
> Hi Alan,
>
> I agree with Xuefu and what was suggested in your statement. I was
> thinking we'd release the next release as 0.15 and then later there
> would be 1.0 off trunk (e.g. what would have been 0.16) and thus be
> superset (minus anything we intentionally remove).
>
> As I have said several times, I'd like to release more often so I feel
> we could even start the 1.0 work shortly after the 0.15 release. For
> my part, I do agree with some earlier contributor/user sentiment that
> it would be good to have some basic public API defined for 1.0. I
> don't think that will be too hard as it's more or less obvious what
> our public API is today.
>
> Hope this seems reasonable.
>
> Cheers,
> Brock
> Xuefu Zhang <ma...@cloudera.com>
> January 22, 2015 at 12:31
> 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.
>
> 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.
>
> Having said that, I'd think it makes more sense to release 0.15 as 0.15,
> and later we release 1.0 as the major release that supersedes any previous
> releases. That will fulfill the expectations of a major release.
>
> Thanks,
> Xuefu
>
>
> Alan Gates <ma...@hortonworks.com>
> January 22, 2015 at 12:12
> I had one clarifying question for Brock and Xuefu. Was your proposal
> to still call the branch from trunk you are planning in a few days
> 0.15 (and hence release it as 0.15) and have 1.0 be a later release?
> Or did you want to call what is now 0.15 1.0? If you wanted 1.0 to be
> post 0.15, are you ok with stipulating that the next release from
> trunk after 0.15 (what would have been 0.16) is 1.0?
>
> Alan.
>
Re: Created branch 1.0
Posted by Edward Capriolo <ed...@gmail.com>.
Because we can not really have a stable api if by definition we build
around snapshot dependencies.
On Mon, Feb 9, 2015 at 11:38 AM, Edward Capriolo <ed...@gmail.com>
wrote:
> Question.
>
> https://issues.apache.org/jira/browse/HIVE-8614
>
> Did we not just agree in this thread that hive will no long have
> dependency that are SNAPSHOT?
>
> On Fri, Jan 23, 2015 at 1:06 AM, Brock Noland <br...@cloudera.com> wrote:
>
>> Hi Alan,
>>
>> I agree with Xuefu and what was suggested in your statement. I was
>> thinking we'd release the next release as 0.15 and then later there
>> would be 1.0 off trunk (e.g. what would have been 0.16) and thus be
>> superset (minus anything we intentionally remove).
>>
>> As I have said several times, I'd like to release more often so I feel
>> we could even start the 1.0 work shortly after the 0.15 release. For
>> my part, I do agree with some earlier contributor/user sentiment that
>> it would be good to have some basic public API defined for 1.0. I
>> don't think that will be too hard as it's more or less obvious what
>> our public API is today.
>>
>> Hope this seems reasonable.
>>
>> Cheers,
>> Brock
>>
>> On Thu, Jan 22, 2015 at 2:31 PM, Xuefu Zhang <xz...@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.
>> >
>> > 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.
>> >
>> > Having said that, I'd think it makes more sense to release 0.15 as 0.15,
>> > and later we release 1.0 as the major release that supersedes any
>> previous
>> > releases. That will fulfill the expectations of a major release.
>> >
>> > Thanks,
>> > Xuefu
>> >
>> > On Thu, Jan 22, 2015 at 12:12 PM, Alan Gates <ga...@hortonworks.com>
>> wrote:
>> >
>> >> I had one clarifying question for Brock and Xuefu. Was your proposal
>> to
>> >> still call the branch from trunk you are planning in a few days 0.15
>> (and
>> >> hence release it as 0.15) and have 1.0 be a later release? Or did you
>> want
>> >> to call what is now 0.15 1.0? If you wanted 1.0 to be post 0.15, are
>> you
>> >> ok with stipulating that the next release from trunk after 0.15 (what
>> would
>> >> have been 0.16) is 1.0?
>> >>
>> >> Alan.
>> >>
>> >> Thejas Nair <th...@hortonworks.com>
>> >> January 22, 2015 at 12:04
>> >> Brock, Xuefu,
>> >>
>> >> We seem to have trouble reaching to a consensus here. (Please see my
>> >> arguments why I don't see this causing confusions, and let me know if
>> >> it changes your opinion).
>> >> How should we move forward ? Do you think we need to go through a
>> >> formal vote regarding the release plan as per hive by-laws ?
>> >>
>> >>
>> >> Thejas Nair <th...@hortonworks.com>
>> >> January 22, 2015 at 10:38
>> >> I don't see any reasons for confusion.
>> >> From a user perspective, 1.0 is going to have a super set of changes of
>> >> 0.14.
>> >> 1.1 (based on planned 0.15 release) will have a super set of changes in
>> >> 1.0 .
>> >>
>> >>
>> >> Xuefu Zhang <xz...@cloudera.com>
>> >> January 21, 2015 at 22:47
>> >> I strongly believe that the concept of 1.0 out of a branch as proposed
>> is
>> >> creating the greatest confusion in the community. If for any reason
>> that
>> >> 1.0 cannot be cut from the trunk, that means that we are not ready and
>> so
>> >> shall wait until so before considering such a release. Thus, I'd -1 on
>> this
>> >> proposal.
>> >>
>> >> Thanks,
>> >> Xuefu
>> >>
>> >>
>> >> Gopal V <go...@apache.org>
>> >> January 21, 2015 at 22:29
>> >> On 1/21/15, 7:09 PM, Brock Noland wrote:
>> >>
>> >> Too be clear I strongly feel creating 1.0 from 0.14 will be confusing.
>> In
>> >> fact it's already crrated confusion amongst folks on this list.
>> >> Furthermore
>> >> 1.0 should be created from trunk and be a superset of previous
>> releases.
>> >>
>> >>
>> >> I don't think there is any confusion over that - 1.0 is a long-term
>> >> maintenance which is going to be a super-set of all *critical fixes*
>> made
>> >> from here on (emphasis).
>> >>
>> >> In fact, a long-term support release should be released off an actively
>> >> updated maintenance branch, which has been baked-in and never from the
>> >> trunk.
>> >>
>> >> Those who have followed the earlier mails would realize that the most
>> >> important "feature" about this branch is to stick to only long term
>> >> maintenance - which in effect is adopting HBase's successful idea.
>> >>
>> >> That is just plain solid engineering.
>> >>
>> >> Anyway, it would be in the best interests of the larger community, to
>> find
>> >> out who else finds that approach confusing.
>> >>
>> >> Brock, I'm not sure whether you are confused or whether you think other
>> >> people will be confused (and if so, why?).
>> >>
>> >> Cheers,
>> >> Gopal
>> >>
>> >> On Wed, Jan 21, 2015 at 6:05 PM, Vikram Dixit K <
>> vikram.dixit@gmail.com>
>> >> <vi...@gmail.com>
>> >> wrote:
>> >>
>> >> @Brock,
>> >>
>> >> I created this branch from 0.14. I created this branch based on the
>> email
>> >> thread discussing 1.0,
>> >>
>> >> http://search-hadoop.com/m/8er9YGX8g2
>> >>
>> >> where you had said you agreed with the suggestion from Enis from HBase
>> who
>> >> said that we should base 1.0 on a stable version rather than making it
>> a
>> >> feature release.
>> >>
>> >> @Lefty,
>> >>
>> >> You are right in that branch 0.14 has been made 1.0. You are also right
>> >> that 0.15 would be 1.1.0 and we should capture that.
>> >>
>> >> Regards
>> >> Vikram.
>> >>
>> >> On Wed, Jan 21, 2015 at 5:13 PM, Thejas Nair <th...@hortonworks.com>
>> >> <th...@hortonworks.com>
>> >>
>> >> wrote:
>> >>
>> >>
>> >> Hi Lefty,
>> >> Yes, you are right. Anything that is not fixed in 0.14 and is fixed in
>> >> 1.0 would have 1.0 as the fixed version.
>> >> Yes, 0.15.0 would then become 1.1.0 .
>> >>
>> >> Yes, it is a good idea to document this translation somewhere.
>> >>
>> >>
>> >> On Wed, Jan 21, 2015 at 3:28 PM, Lefty Leverenz <
>> leftyleverenz@gmail.com>
>> >> <le...@gmail.com>
>> >> wrote:
>> >> > So my initial impression was correct -- instead of calling it release
>> >> > 0.14.1, we're calling it 1.0.0. Or am I hopelessly confused?
>> >> >
>> >> > Will 0.15.0 be 1.1.0? (If so, I'll need to edit a dozen wikidocs.)
>> >> >
>> >> > Will release numbers get changed in JIRA issues? Presumably that's
>> not
>> >> > possible in old comments, so we should document the equivalences
>> >> > somewhere. A JIRA issue for that with a well-phrased summary could
>> help
>> >> > future searchers.
>> >> >
>> >> >
>> >> > -- Lefty
>> >> >
>> >> > On Wed, Jan 21, 2015 at 2:47 PM, Eugene Koifman <
>> >> ekoifman@hortonworks.com>
>> >> > wrote:
>> >> >
>> >> >> could we include HIVE-9390 & HIVE-9404? This has been committed to
>> >> trunk.
>> >> >> They add useful retry logic to support insert/update/delete
>> >> functionality.
>> >> >>
>> >> >> On Wed, Jan 21, 2015 at 1:06 PM, Vikram Dixit K <
>> >>
>> >> vikram.dixit@gmail.com
>> >>
>> >> >
>> >> >> wrote:
>> >> >>
>> >> >> > Hi Folks,
>> >> >> >
>> >> >> > I have created branch 1.0 as discussed earlier. All the jiras that
>> >> have
>> >> >> > 0.14 as the fix version should be committed to 1.0 branch instead.
>> >>
>> >> The
>> >>
>> >> >> list
>> >> >> > of jiras that are being tracked for 1.0 are as follows:
>> >> >> >
>> >> >> > HIVE-8485
>> >> >> > HIVE-9053
>> >> >> > HIVE-8996.
>> >> >> >
>> >> >> > Please let me know if you want to include more jiras here. I am
>> >> working
>> >> >> on
>> >> >> > generating javadocs for this. I hope to have an RC out once these
>> >> jiras
>> >> >> get
>> >> >> > in.
>> >> >> >
>> >> >> > Regards
>> >> >> > Vikram.
>> >> >> >
>> >> >> > On Tue, Jan 20, 2015 at 1:00 PM, Vaibhav Gumashta <
>> >> >> > vgumashta@hortonworks.com
>> >> >> > > wrote:
>> >> >> >
>> >> >> > > Hi Vikram,
>> >> >> > >
>> >> >> > > I'd like to get this in: HIVE-8890
>> >> >> > > <https://issues.apache.org/jira/browse/HIVE-8890>
>> >> <https://issues.apache.org/jira/browse/HIVE-8890> [HiveServer2
>> >> dynamic
>> >> >> > > service discovery: use persistent ephemeral nodes curator
>> recipe].
>> >> >> > >
>> >> >> > > Thanks,
>> >> >> > > --Vaibhav
>> >> >> > >
>> >> >> > > On Mon, Jan 19, 2015 at 9:29 PM, Alan Gates <
>> gates@hortonworks.com
>> >>
>> >>
>> >> >> > wrote:
>> >> >> > >
>> >> >> > > > I'd really like to get HIVE-8966 in there, since it breaks
>> >> streaming
>> >> >> > > > ingest. The patch is ready to go, it's just waiting on a
>> >>
>> >> review,
>> >>
>> >> >> which
>> >> >> > > > Owen has promised to do soon.
>> >> >> > > >
>> >> >> > > > Alan.
>> >> >> > > >
>> >> >> > > > Vikram Dixit K <vi...@gmail.com> <
>> vikram.dixit@gmail.com>
>> >> >> > > > January 19, 2015 at 18:53
>> >> >> > > > Hi All,
>> >> >> > > >
>> >> >> > > > I am going to be creating the branch 1.0 as mentioned earlier,
>> >> >> > tomorrow.
>> >> >> > > I
>> >> >> > > > have the following list of jiras that I want to get committed
>> >>
>> >> to
>> >>
>> >> the
>> >> >> > > branch
>> >> >> > > > before creating an RC.
>> >> >> > > >
>> >> >> > > > HIVE-9112
>> >> >> > > > HIVE-6997 : Delete hive server 1
>> >> >> > > > HIVE-8485
>> >> >> > > > HIVE-9053
>> >> >> > > >
>> >> >> > > > Please let me know if you would like me to include any other
>> >> jiras.
>> >> >> > > >
>> >> >> > > > Thanks
>> >> >> > > > Vikram.
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > On Fri, Jan 16, 2015 at 1:35 PM, Vikram Dixit K <
>> >> >> > vikram.dixit@gmail.com>
>> >> >> > > > <vi...@gmail.com> <vi...@gmail.com>
>> >> >> > > >
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > Thejas Nair <th...@hortonworks.com> <th...@hortonworks.com>
>> >> >> > > > January 1, 2015 at 10:23
>> >> >> > > > Yes, 1.0 is a good opportunity to remove some of the
>> deprecated
>> >> >> > > > components. The change to remove HiveServer1 is already there
>> >>
>> >> in
>> >>
>> >> >> trunk
>> >> >> > > > , we should include that.
>> >> >> > > > We can also use 1.0 release to clarify the public vs private
>> >> status
>> >> >> of
>> >> >> > > > some of the APIs.
>> >> >> > > >
>> >> >> > > > Thanks for the reminder about the documentation status of
>> >>
>> >> 1.0. I
>> >>
>> >> will
>> >> >> > > > look at some of them.
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > On Wed, Dec 31, 2014 at 12:12 AM, Lefty Leverenz
>> >> >> > > >
>> >> >> > > > Lefty Leverenz <le...@gmail.com>
>> >> <le...@gmail.com>
>> >> >> > > > December 31, 2014 at 0:12
>> >> >> > > > Oh, now I get it. The 1.0.0 *branch* of Hive. Okay.
>> >> >> > > >
>> >> >> > > > -- Lefty
>> >> >> > > >
>> >> >> > > > On Tue, Dec 30, 2014 at 11:43 PM, Lefty Leverenz <
>> >> >> > > leftyleverenz@gmail.com>
>> >> >> > > > <le...@gmail.com> <le...@gmail.com>
>> >> >> > > >
>> >> >> > > > Lefty Leverenz <le...@gmail.com>
>> >> <le...@gmail.com>
>> >> >> > > > December 30, 2014 at 23:43
>> >> >> > > > I thought x.x.# releases were just for fixups, x.#.x could
>> >>
>> >> include
>> >>
>> >> >> new
>> >> >> > > > features, and #.x.x were major releases that might have some
>> >> >> > > > backward-incompatible changes. But I guess we haven't agreed
>> >>
>> >> on
>> >>
>> >> that.
>> >> >> > > >
>> >> >> > > > As for documentation, we still have 84 jiras with TODOC14
>> >>
>> >> labels
>> >>
>> >> >> > > >
>> >> >> > > > <
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC14
>> >>
>> >> >> > > >
>> >> >> > > > <
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC14
>> >>
>> >> >> > > >
>> >> >> > > > .
>> >> >> > > > Not to mention 25 TODOC13 labels
>> >> >> > > >
>> >> >> > > > <
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC13
>> >>
>> >> >> > > >
>> >> >> > > > <
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC13
>> >>
>> >> >> > > >
>> >> >> > > > ,
>> >> >> > > > eleven TODOC12
>> >> >> > > >
>> >> >> > > > <
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC12
>> >>
>> >> >> > > >
>> >> >> > > > <
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC12
>> >>
>> >> >> > > >
>> >> >> > > > ,
>> >> >> > > > seven TODOC11
>> >> >> > > >
>> >> >> > > > <
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC11
>> >>
>> >> >> > > >
>> >> >> > > > <
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC11
>> >>
>> >> >> > > >
>> >> >> > > > ,
>> >> >> > > > and seven TODOC10
>> >> >> > > >
>> >> >> > > > <
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC10
>> >>
>> >> >> > > >
>> >> >> > > > <
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> >>
>> >>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HIVE%20AND%20labels%20%3D%20TODOC10
>> >>
>> >> >> > > >
>> >> >> > > > .
>> >> >> > > >
>> >> >> > > > That's 134 doc tasks to finish for a Hive 1.0.0 release --
>> >> preferably
>> >> >> > by
>> >> >> > > > the release date, not after. Because expectations are higher
>> >>
>> >> for
>> >>
>> >> >> 1.0.0
>> >> >> > > > releases.
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > -- Lefty
>> >> >> > > >
>> >> >> > > > On Tue, Dec 30, 2014 at 5:23 PM, Vikram Dixit K <
>> >> >> > vikram.dixit@gmail.com>
>> >> >> > > > <vi...@gmail.com> <vi...@gmail.com>
>> >> >> > > >
>> >> >> > > > Vikram Dixit K <vi...@gmail.com> <
>> vikram.dixit@gmail.com>
>> >> >> > > > December 30, 2014 at 17:23
>> >> >> > > > Hi Folks,
>> >> >> > > >
>> >> >> > > > Given that there have been a number of fixes that have gone
>> >>
>> >> into
>> >>
>> >> >> branch
>> >> >> > > > 0.14 in the past 8 weeks, I would like to make a release
>> >>
>> >> of
>> >> 0.14.1
>> >>
>> >> >> > soon.
>> >> >> > > I
>> >> >> > > > would like to fix some of the release issues as well this
>> >>
>> >> time
>> >>
>> >> >> around.
>> >> >> > I
>> >> >> > > am
>> >> >> > > > thinking of some time around 15th January for getting a RC
>> >>
>> >> out.
>> >>
>> >> >> Please
>> >> >> > > let
>> >> >> > > > me know if you have any concerns. Also, from a previous
>> thread,
>> >>
>> >> I
>> >>
>> >> >> would
>> >> >> > > > like to make this release the 1.0 branch of hive. The process
>> >>
>> >> for
>> >>
>> >> >> > getting
>> >> >> > > > jiras into this release is going to be the same as the
>> previous
>> >> one
>> >> >> > viz.:
>> >> >> > > >
>> >> >> > > > 1. Mark the jira with fix version 0.14.1 and update the status
>> >>
>> >> to
>> >>
>> >> >> > > > blocker/critical.
>> >> >> > > > 2. If a committer +1s the patch for 0.14.1, it is good to
>> >>
>> >> go in.
>> >>
>> >> >> Please
>> >> >> > > > mention me in the jira in case you are not sure if the jira
>> >>
>> >> should
>> >>
>> >> >> make
>> >> >> > > it
>> >> >> > > > for 0.14.1.
>> >> >> > > >
>> >> >> > > > Thanks
>> >> >> > > > Vikram.
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > 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
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Thanks,
>> >> >> Eugene
>> >> >>
>> >> >> --
>> >> >> 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
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> 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.
>> >>
>>
>
>