You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Jonathan Hsieh <jo...@cloudera.com> on 2013/04/04 17:40:09 UTC
Marking fix version
Hey all,
I just wanted to make sure we are on the same page here when we committing
code and that we are consistent when marking fix version in the jira. Its
pretty important that we get this right because our release notes are
generated from these as of 0.94.
Here's what I'm doing and suggesting
Commit only to trunk: Mark with 0.98
Commit to 0.95 and trunk : Mark with 0.98, 0.96, and 0.95.x
Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.96, 0.95.x, and
0.94.x
Commit to 89-fb: Mark with 89-fb.
Commit site fixes: no version
My understanding is that 0.96 will be a branch off of 0.95 -- so any fix to
0.95 is a fix to 0.96 until 0.96 branches.
Thanks,
Jon.
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com
Re: Marking fix version
Posted by lars hofhansl <la...@apache.org>.
Not necessarily. 0.95 is special in that it is a known "experimental" version to play with.
________________________________
From: Nick Dimiduk <nd...@gmail.com>
To: dev@hbase.apache.org; lars hofhansl <la...@apache.org>
Sent: Thursday, April 4, 2013 11:55 AM
Subject: Re: Marking fix version
By this logic, 0.98 tag should be renamed to 0.97, yes?
On Thu, Apr 4, 2013 at 10:33 AM, lars hofhansl <la...@apache.org> wrote:
> Yes, I think we should remove the 0.96 tag. Stack said the other day that
> he should have just renamed 0.96 to 0.95 rather than moving all the issues.
>
> The rest is already what I have been doing for issues I am committing (so
> +1 :) ), but I did notice that not all issues are tagged correctly.
>
>
> -- Lars
>
>
>
> ________________________________
> From: Jonathan Hsieh <jo...@cloudera.com>
> To: dev@hbase.apache.org; lars hofhansl <la...@apache.org>
> Sent: Thursday, April 4, 2013 10:15 AM
> Subject: Re: Marking fix version
>
>
> The argument for excluding the 0.96 tag makes sense. Can we agree to do
> this:
>
>
> Commit only to trunk: Mark with 0.98
> Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
> Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
>
> Commit to 89-fb: Mark with 89-fb.
> Commit site fixes: no version
>
> Should we remove 0.96 tag for now until the branch appears again?
>
> Thanks,
> Jon.
>
> On Thu, Apr 4, 2013 at 10:10 AM, lars hofhansl <la...@apache.org> wrote:
>
> Thank Jon,
> >
> >I do not think we have to include anticipated future branches in the tags.
> >The release notes are not accumulative but list changes made for each
> release.
> >
> >So if something is in 0.95.x a 0.96 tag neither needed nor wanted (IMHO)
> until we actually have a *parallel* 0.96 branch.
> >
> >That is why all 0.95+trunk changes *have* to be tagged with 0.98 as well,
> because at this point the two branches are in parallel. Actually we should
> go through and make that so in jira.
> >
> >That means the 0.96 tag is not needed right now (and in fact will make
> just confusing, because at the time we do release 0.96 we'll see the same
> issue in the release notes twice)
> >
> >-- Lars
> >
> >
> >
> >________________________________
> > From: Jonathan Hsieh <jo...@cloudera.com>
> >To: dev@hbase.apache.org
> >Sent: Thursday, April 4, 2013 8:40 AM
> >Subject: Marking fix version
> >
> >
> >Hey all,
> >
> >I just wanted to make sure we are on the same page here when we committing
> >code and that we are consistent when marking fix version in the jira. Its
> >pretty important that we get this right because our release notes are
> >generated from these as of 0.94.
> >
> >Here's what I'm doing and suggesting
> >
> >Commit only to trunk: Mark with 0.98
> >Commit to 0.95 and trunk : Mark with 0.98, 0.96, and 0.95.x
> >Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.96, 0.95.x, and
> >0.94.x
> >Commit to 89-fb: Mark with 89-fb.
> >Commit site fixes: no version
> >
> >My understanding is that 0.96 will be a branch off of 0.95 -- so any fix
> to
> >0.95 is a fix to 0.96 until 0.96 branches.
> >
> >Thanks,
> >Jon.
> >
> >--
> >// Jonathan Hsieh (shay)
> >// Software Engineer, Cloudera
> >// jon@cloudera.com
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
>
> // jon@cloudera.com
>
Re: Marking fix version
Posted by Nick Dimiduk <nd...@gmail.com>.
By this logic, 0.98 tag should be renamed to 0.97, yes?
On Thu, Apr 4, 2013 at 10:33 AM, lars hofhansl <la...@apache.org> wrote:
> Yes, I think we should remove the 0.96 tag. Stack said the other day that
> he should have just renamed 0.96 to 0.95 rather than moving all the issues.
>
> The rest is already what I have been doing for issues I am committing (so
> +1 :) ), but I did notice that not all issues are tagged correctly.
>
>
> -- Lars
>
>
>
> ________________________________
> From: Jonathan Hsieh <jo...@cloudera.com>
> To: dev@hbase.apache.org; lars hofhansl <la...@apache.org>
> Sent: Thursday, April 4, 2013 10:15 AM
> Subject: Re: Marking fix version
>
>
> The argument for excluding the 0.96 tag makes sense. Can we agree to do
> this:
>
>
> Commit only to trunk: Mark with 0.98
> Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
> Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
>
> Commit to 89-fb: Mark with 89-fb.
> Commit site fixes: no version
>
> Should we remove 0.96 tag for now until the branch appears again?
>
> Thanks,
> Jon.
>
> On Thu, Apr 4, 2013 at 10:10 AM, lars hofhansl <la...@apache.org> wrote:
>
> Thank Jon,
> >
> >I do not think we have to include anticipated future branches in the tags.
> >The release notes are not accumulative but list changes made for each
> release.
> >
> >So if something is in 0.95.x a 0.96 tag neither needed nor wanted (IMHO)
> until we actually have a *parallel* 0.96 branch.
> >
> >That is why all 0.95+trunk changes *have* to be tagged with 0.98 as well,
> because at this point the two branches are in parallel. Actually we should
> go through and make that so in jira.
> >
> >That means the 0.96 tag is not needed right now (and in fact will make
> just confusing, because at the time we do release 0.96 we'll see the same
> issue in the release notes twice)
> >
> >-- Lars
> >
> >
> >
> >________________________________
> > From: Jonathan Hsieh <jo...@cloudera.com>
> >To: dev@hbase.apache.org
> >Sent: Thursday, April 4, 2013 8:40 AM
> >Subject: Marking fix version
> >
> >
> >Hey all,
> >
> >I just wanted to make sure we are on the same page here when we committing
> >code and that we are consistent when marking fix version in the jira. Its
> >pretty important that we get this right because our release notes are
> >generated from these as of 0.94.
> >
> >Here's what I'm doing and suggesting
> >
> >Commit only to trunk: Mark with 0.98
> >Commit to 0.95 and trunk : Mark with 0.98, 0.96, and 0.95.x
> >Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.96, 0.95.x, and
> >0.94.x
> >Commit to 89-fb: Mark with 89-fb.
> >Commit site fixes: no version
> >
> >My understanding is that 0.96 will be a branch off of 0.95 -- so any fix
> to
> >0.95 is a fix to 0.96 until 0.96 branches.
> >
> >Thanks,
> >Jon.
> >
> >--
> >// Jonathan Hsieh (shay)
> >// Software Engineer, Cloudera
> >// jon@cloudera.com
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
>
> // jon@cloudera.com
>
Re: Marking fix version
Posted by Stack <st...@duboce.net>.
I was just marking issues in 0.95 and trunk w/ 0.95. Let me go back and
fix so has 0.98 on it too. Let me also remove 0.96 for now. We can bring
it back later (or just skip it and go to 1.0?).
St.Ack
On Thu, Apr 4, 2013 at 10:33 AM, lars hofhansl <la...@apache.org> wrote:
> Yes, I think we should remove the 0.96 tag. Stack said the other day that
> he should have just renamed 0.96 to 0.95 rather than moving all the issues.
>
> The rest is already what I have been doing for issues I am committing (so
> +1 :) ), but I did notice that not all issues are tagged correctly.
>
>
> -- Lars
>
>
>
> ________________________________
> From: Jonathan Hsieh <jo...@cloudera.com>
> To: dev@hbase.apache.org; lars hofhansl <la...@apache.org>
> Sent: Thursday, April 4, 2013 10:15 AM
> Subject: Re: Marking fix version
>
>
> The argument for excluding the 0.96 tag makes sense. Can we agree to do
> this:
>
>
> Commit only to trunk: Mark with 0.98
> Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
> Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
>
> Commit to 89-fb: Mark with 89-fb.
> Commit site fixes: no version
>
> Should we remove 0.96 tag for now until the branch appears again?
>
> Thanks,
> Jon.
>
> On Thu, Apr 4, 2013 at 10:10 AM, lars hofhansl <la...@apache.org> wrote:
>
> Thank Jon,
> >
> >I do not think we have to include anticipated future branches in the tags.
> >The release notes are not accumulative but list changes made for each
> release.
> >
> >So if something is in 0.95.x a 0.96 tag neither needed nor wanted (IMHO)
> until we actually have a *parallel* 0.96 branch.
> >
> >That is why all 0.95+trunk changes *have* to be tagged with 0.98 as well,
> because at this point the two branches are in parallel. Actually we should
> go through and make that so in jira.
> >
> >That means the 0.96 tag is not needed right now (and in fact will make
> just confusing, because at the time we do release 0.96 we'll see the same
> issue in the release notes twice)
> >
> >-- Lars
> >
> >
> >
> >________________________________
> > From: Jonathan Hsieh <jo...@cloudera.com>
> >To: dev@hbase.apache.org
> >Sent: Thursday, April 4, 2013 8:40 AM
> >Subject: Marking fix version
> >
> >
> >Hey all,
> >
> >I just wanted to make sure we are on the same page here when we committing
> >code and that we are consistent when marking fix version in the jira. Its
> >pretty important that we get this right because our release notes are
> >generated from these as of 0.94.
> >
> >Here's what I'm doing and suggesting
> >
> >Commit only to trunk: Mark with 0.98
> >Commit to 0.95 and trunk : Mark with 0.98, 0.96, and 0.95.x
> >Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.96, 0.95.x, and
> >0.94.x
> >Commit to 89-fb: Mark with 89-fb.
> >Commit site fixes: no version
> >
> >My understanding is that 0.96 will be a branch off of 0.95 -- so any fix
> to
> >0.95 is a fix to 0.96 until 0.96 branches.
> >
> >Thanks,
> >Jon.
> >
> >--
> >// Jonathan Hsieh (shay)
> >// Software Engineer, Cloudera
> >// jon@cloudera.com
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
>
> // jon@cloudera.com
>
Re: Marking fix version
Posted by lars hofhansl <la...@apache.org>.
Yes, I think we should remove the 0.96 tag. Stack said the other day that he should have just renamed 0.96 to 0.95 rather than moving all the issues.
The rest is already what I have been doing for issues I am committing (so +1 :) ), but I did notice that not all issues are tagged correctly.
-- Lars
________________________________
From: Jonathan Hsieh <jo...@cloudera.com>
To: dev@hbase.apache.org; lars hofhansl <la...@apache.org>
Sent: Thursday, April 4, 2013 10:15 AM
Subject: Re: Marking fix version
The argument for excluding the 0.96 tag makes sense. Can we agree to do this:
Commit only to trunk: Mark with 0.98
Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
Commit to 89-fb: Mark with 89-fb.
Commit site fixes: no version
Should we remove 0.96 tag for now until the branch appears again?
Thanks,
Jon.
On Thu, Apr 4, 2013 at 10:10 AM, lars hofhansl <la...@apache.org> wrote:
Thank Jon,
>
>I do not think we have to include anticipated future branches in the tags.
>The release notes are not accumulative but list changes made for each release.
>
>So if something is in 0.95.x a 0.96 tag neither needed nor wanted (IMHO) until we actually have a *parallel* 0.96 branch.
>
>That is why all 0.95+trunk changes *have* to be tagged with 0.98 as well, because at this point the two branches are in parallel. Actually we should go through and make that so in jira.
>
>That means the 0.96 tag is not needed right now (and in fact will make just confusing, because at the time we do release 0.96 we'll see the same issue in the release notes twice)
>
>-- Lars
>
>
>
>________________________________
> From: Jonathan Hsieh <jo...@cloudera.com>
>To: dev@hbase.apache.org
>Sent: Thursday, April 4, 2013 8:40 AM
>Subject: Marking fix version
>
>
>Hey all,
>
>I just wanted to make sure we are on the same page here when we committing
>code and that we are consistent when marking fix version in the jira. Its
>pretty important that we get this right because our release notes are
>generated from these as of 0.94.
>
>Here's what I'm doing and suggesting
>
>Commit only to trunk: Mark with 0.98
>Commit to 0.95 and trunk : Mark with 0.98, 0.96, and 0.95.x
>Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.96, 0.95.x, and
>0.94.x
>Commit to 89-fb: Mark with 89-fb.
>Commit site fixes: no version
>
>My understanding is that 0.96 will be a branch off of 0.95 -- so any fix to
>0.95 is a fix to 0.96 until 0.96 branches.
>
>Thanks,
>Jon.
>
>--
>// Jonathan Hsieh (shay)
>// Software Engineer, Cloudera
>// jon@cloudera.com
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com
Re: Marking fix version
Posted by Andrew Purtell <ap...@apache.org>.
Ok.
On Thu, Apr 4, 2013 at 10:15 AM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> The argument for excluding the 0.96 tag makes sense. Can we agree to do
> this:
>
> Commit only to trunk: Mark with 0.98
> Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
> Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
> Commit to 89-fb: Mark with 89-fb.
> Commit site fixes: no version
>
> Should we remove 0.96 tag for now until the branch appears again?
>
> Thanks,
> Jon.
>
> On Thu, Apr 4, 2013 at 10:10 AM, lars hofhansl <la...@apache.org> wrote:
>
> > Thank Jon,
> >
> > I do not think we have to include anticipated future branches in the
> tags.
> > The release notes are not accumulative but list changes made for each
> > release.
> >
> > So if something is in 0.95.x a 0.96 tag neither needed nor wanted (IMHO)
> > until we actually have a *parallel* 0.96 branch.
> >
> > That is why all 0.95+trunk changes *have* to be tagged with 0.98 as well,
> > because at this point the two branches are in parallel. Actually we
> should
> > go through and make that so in jira.
> >
> > That means the 0.96 tag is not needed right now (and in fact will make
> > just confusing, because at the time we do release 0.96 we'll see the same
> > issue in the release notes twice)
> >
> > -- Lars
> >
> >
> >
> > ________________________________
> > From: Jonathan Hsieh <jo...@cloudera.com>
> > To: dev@hbase.apache.org
> > Sent: Thursday, April 4, 2013 8:40 AM
> > Subject: Marking fix version
> >
> > Hey all,
> >
> > I just wanted to make sure we are on the same page here when we
> committing
> > code and that we are consistent when marking fix version in the jira.
> Its
> > pretty important that we get this right because our release notes are
> > generated from these as of 0.94.
> >
> > Here's what I'm doing and suggesting
> >
> > Commit only to trunk: Mark with 0.98
> > Commit to 0.95 and trunk : Mark with 0.98, 0.96, and 0.95.x
> > Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.96, 0.95.x, and
> > 0.94.x
> > Commit to 89-fb: Mark with 89-fb.
> > Commit site fixes: no version
> >
> > My understanding is that 0.96 will be a branch off of 0.95 -- so any fix
> to
> > 0.95 is a fix to 0.96 until 0.96 branches.
> >
> > Thanks,
> > Jon.
> >
> > --
> > // Jonathan Hsieh (shay)
> > // Software Engineer, Cloudera
> > // jon@cloudera.com
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Marking fix version
Posted by Jonathan Hsieh <jo...@cloudera.com>.
Thanks stack!
On Fri, Apr 5, 2013 at 11:18 PM, Stack <st...@duboce.net> wrote:
> On Thu, Apr 4, 2013 at 10:15 AM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
> > The argument for excluding the 0.96 tag makes sense. Can we agree to do
> > this:
> >
> > Commit only to trunk: Mark with 0.98
> > Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
> > Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
> > Commit to 89-fb: Mark with 89-fb.
> > Commit site fixes: no version
> >
> >
> I added the above agreement to the refguide:
> http://hbase.apache.org/book.html#decisions
>
> I fixed issues that were resolved w/ 0.95.0 adding 0.98.0 as per above.
>
>
> > Should we remove 0.96 tag for now until the branch appears again?
> >
>
> I removed it.
>
> Good on you lads,
> St.Ack
>
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com
Re: Marking fix version
Posted by Stack <st...@duboce.net>.
I am going through the 0.95-0.96 issues applying this decision now.
St.Ack
On Fri, Apr 5, 2013 at 11:18 PM, Stack <st...@duboce.net> wrote:
> On Thu, Apr 4, 2013 at 10:15 AM, Jonathan Hsieh <jo...@cloudera.com> wrote:
>
>> The argument for excluding the 0.96 tag makes sense. Can we agree to do
>> this:
>>
>> Commit only to trunk: Mark with 0.98
>> Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
>> Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
>> Commit to 89-fb: Mark with 89-fb.
>> Commit site fixes: no version
>>
>>
> I added the above agreement to the refguide:
> http://hbase.apache.org/book.html#decisions
>
> I fixed issues that were resolved w/ 0.95.0 adding 0.98.0 as per above.
>
>
>> Should we remove 0.96 tag for now until the branch appears again?
>>
>
> I removed it.
>
> Good on you lads,
> St.Ack
>
Re: Marking fix version
Posted by Stack <st...@duboce.net>.
On Thu, Apr 4, 2013 at 10:15 AM, Jonathan Hsieh <jo...@cloudera.com> wrote:
> The argument for excluding the 0.96 tag makes sense. Can we agree to do
> this:
>
> Commit only to trunk: Mark with 0.98
> Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
> Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
> Commit to 89-fb: Mark with 89-fb.
> Commit site fixes: no version
>
>
I added the above agreement to the refguide:
http://hbase.apache.org/book.html#decisions
I fixed issues that were resolved w/ 0.95.0 adding 0.98.0 as per above.
> Should we remove 0.96 tag for now until the branch appears again?
>
I removed it.
Good on you lads,
St.Ack
Re: Marking fix version
Posted by Jonathan Hsieh <jo...@cloudera.com>.
The argument for excluding the 0.96 tag makes sense. Can we agree to do
this:
Commit only to trunk: Mark with 0.98
Commit to 0.95 and trunk : Mark with 0.98, and 0.95.x
Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.95.x, and 0.94.x
Commit to 89-fb: Mark with 89-fb.
Commit site fixes: no version
Should we remove 0.96 tag for now until the branch appears again?
Thanks,
Jon.
On Thu, Apr 4, 2013 at 10:10 AM, lars hofhansl <la...@apache.org> wrote:
> Thank Jon,
>
> I do not think we have to include anticipated future branches in the tags.
> The release notes are not accumulative but list changes made for each
> release.
>
> So if something is in 0.95.x a 0.96 tag neither needed nor wanted (IMHO)
> until we actually have a *parallel* 0.96 branch.
>
> That is why all 0.95+trunk changes *have* to be tagged with 0.98 as well,
> because at this point the two branches are in parallel. Actually we should
> go through and make that so in jira.
>
> That means the 0.96 tag is not needed right now (and in fact will make
> just confusing, because at the time we do release 0.96 we'll see the same
> issue in the release notes twice)
>
> -- Lars
>
>
>
> ________________________________
> From: Jonathan Hsieh <jo...@cloudera.com>
> To: dev@hbase.apache.org
> Sent: Thursday, April 4, 2013 8:40 AM
> Subject: Marking fix version
>
> Hey all,
>
> I just wanted to make sure we are on the same page here when we committing
> code and that we are consistent when marking fix version in the jira. Its
> pretty important that we get this right because our release notes are
> generated from these as of 0.94.
>
> Here's what I'm doing and suggesting
>
> Commit only to trunk: Mark with 0.98
> Commit to 0.95 and trunk : Mark with 0.98, 0.96, and 0.95.x
> Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.96, 0.95.x, and
> 0.94.x
> Commit to 89-fb: Mark with 89-fb.
> Commit site fixes: no version
>
> My understanding is that 0.96 will be a branch off of 0.95 -- so any fix to
> 0.95 is a fix to 0.96 until 0.96 branches.
>
> Thanks,
> Jon.
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com
>
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com
Re: Marking fix version
Posted by lars hofhansl <la...@apache.org>.
Thank Jon,
I do not think we have to include anticipated future branches in the tags.
The release notes are not accumulative but list changes made for each release.
So if something is in 0.95.x a 0.96 tag neither needed nor wanted (IMHO) until we actually have a *parallel* 0.96 branch.
That is why all 0.95+trunk changes *have* to be tagged with 0.98 as well, because at this point the two branches are in parallel. Actually we should go through and make that so in jira.
That means the 0.96 tag is not needed right now (and in fact will make just confusing, because at the time we do release 0.96 we'll see the same issue in the release notes twice)
-- Lars
________________________________
From: Jonathan Hsieh <jo...@cloudera.com>
To: dev@hbase.apache.org
Sent: Thursday, April 4, 2013 8:40 AM
Subject: Marking fix version
Hey all,
I just wanted to make sure we are on the same page here when we committing
code and that we are consistent when marking fix version in the jira. Its
pretty important that we get this right because our release notes are
generated from these as of 0.94.
Here's what I'm doing and suggesting
Commit only to trunk: Mark with 0.98
Commit to 0.95 and trunk : Mark with 0.98, 0.96, and 0.95.x
Commit to 0.94.x and 0.95, and trunk: Mark with 0.98, 0.96, 0.95.x, and
0.94.x
Commit to 89-fb: Mark with 89-fb.
Commit site fixes: no version
My understanding is that 0.96 will be a branch off of 0.95 -- so any fix to
0.95 is a fix to 0.96 until 0.96 branches.
Thanks,
Jon.
--
// Jonathan Hsieh (shay)
// Software Engineer, Cloudera
// jon@cloudera.com