NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

stack-3
Lets start in on the hardening of hbase-2.0.0. All features are in though
in need of test and polish. There are tasks outstanding around migration
from hbase-1 to hbase-2 and narratives to tell our users around timeout,
etc. We still need to update dependencies, revamp defaults, etc., but the
hbase-2.0.0 countdown has started in earnest.

I intend to cut an alpha in the next day or so just so folks can start
kicking the tires even though we are a good ways from beta [1].

To be clear, we are done w/ 'features' for hbase-2.0.0. Bug fixes and
polish only please from here on out. If you have a borderline item or an
item you just can't do w/o, lets discuss.

I just set the version on master branch to be 3.0.0-SNAPSHOT.

Thanks.
Shout if any issues or in need of clarification on any of the above.
Your hbase-2.0.0 RM.
St.Ack

1.
https://docs.google.com/document/d/1WCsVlnHjJeKUcl7wHwqb4z9iEu_ktczrlKHK8N4SZzs/edit#
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Josh Elser-2


On 6/7/17 1:17 AM, Stack wrote:

> Lets start in on the hardening of hbase-2.0.0. All features are in though
> in need of test and polish. There are tasks outstanding around migration
> from hbase-1 to hbase-2 and narratives to tell our users around timeout,
> etc. We still need to update dependencies, revamp defaults, etc., but the
> hbase-2.0.0 countdown has started in earnest.
>
> I intend to cut an alpha in the next day or so just so folks can start
> kicking the tires even though we are a good ways from beta [1].
>
> To be clear, we are done w/ 'features' for hbase-2.0.0. Bug fixes and
> polish only please from here on out. If you have a borderline item or an
> item you just can't do w/o, lets discuss.

Yay, progress! Thanks for pushing, S.

> I just set the version on master branch to be 3.0.0-SNAPSHOT.

I was just thinking about this one this morning: would master become
2.1.0 or 3.0.0?

I'd guess that the intent is to put more emphasis on the "x" instead of
the "y" and "z" (for a version string "x.y.z")? We all on board with
that plan too, for better or for worse? :)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Sean Busbey-2
On Wed, Jun 7, 2017 at 10:04 AM, Josh Elser <[hidden email]> wrote:

>
>
> On 6/7/17 1:17 AM, Stack wrote:
>>
>
>> I just set the version on master branch to be 3.0.0-SNAPSHOT.
>
>
> I was just thinking about this one this morning: would master become 2.1.0
> or 3.0.0?
>
> I'd guess that the intent is to put more emphasis on the "x" instead of the
> "y" and "z" (for a version string "x.y.z")? We all on board with that plan
> too, for better or for worse? :)

yeah, this is the same bit we did when branch-1 was created off of
master last major release. We need a place to put the breaking stuff.

Hopefully we can exercise a more planned out approach to how long
master waits for the next branch-x.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Josh Elser-2
In reply to this post by Josh Elser-2

On 6/7/17 11:04 AM, Josh Elser wrote:

>
>
> On 6/7/17 1:17 AM, Stack wrote:
>> Lets start in on the hardening of hbase-2.0.0. All features are in though
>> in need of test and polish. There are tasks outstanding around migration
>> from hbase-1 to hbase-2 and narratives to tell our users around timeout,
>> etc. We still need to update dependencies, revamp defaults, etc., but the
>> hbase-2.0.0 countdown has started in earnest.
>>
>> I intend to cut an alpha in the next day or so just so folks can start
>> kicking the tires even though we are a good ways from beta [1].
>>
>> To be clear, we are done w/ 'features' for hbase-2.0.0. Bug fixes and
>> polish only please from here on out. If you have a borderline item or an
>> item you just can't do w/o, lets discuss.
>
> Yay, progress! Thanks for pushing, S.
>
>> I just set the version on master branch to be 3.0.0-SNAPSHOT.
>
> I was just thinking about this one this morning: would master become
> 2.1.0 or 3.0.0?
>
> I'd guess that the intent is to put more emphasis on the "x" instead of
> the "y" and "z" (for a version string "x.y.z")? We all on board with
> that plan too, for better or for worse? :)

Clarification: I'm really trying to ask the question, should we have a
"branch-2.0" for tracking HBase-2.0.0 instead of a "branch-2"?

I think trying to avoid multiple, concurrently developed 2.y release
lines would help our sanity (do more 2.y.0 releases, fewer 2.y.z
releases), but that would mean that we're consciously pushing towards a
faster cadence for x.0.0 releases to come. If this is the case,
"branch-2" makes sense; however, if the plan would be to stick with how
HBase-1.y.z has been going, I'd expect a "branch-2.0" (and a "branch-2").
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Sean Busbey-2
In reply to this post by Sean Busbey-2
On Wed, Jun 7, 2017 at 10:07 AM, Sean Busbey <[hidden email]> wrote:

> On Wed, Jun 7, 2017 at 10:04 AM, Josh Elser <[hidden email]> wrote:
>>
>>
>> On 6/7/17 1:17 AM, Stack wrote:
>>>
>>
>>> I just set the version on master branch to be 3.0.0-SNAPSHOT.
>>
>>
>> I was just thinking about this one this morning: would master become 2.1.0
>> or 3.0.0?
>>
>> I'd guess that the intent is to put more emphasis on the "x" instead of the
>> "y" and "z" (for a version string "x.y.z")? We all on board with that plan
>> too, for better or for worse? :)
>
> yeah, this is the same bit we did when branch-1 was created off of
> master last major release. We need a place to put the breaking stuff.
>
> Hopefully we can exercise a more planned out approach to how long
> master waits for the next branch-x.


Thinking about this more, did we document the branching strategy anywhere?

Like, this is what I expect is going to happen, but it occurs to me
that I can't point at why:

* branch-2 made off of master
* alpha/beta releases tagged off of branch-2
* branch-2.0 made off of branch-2
* 2.0.0 GA release tagged off of branch-2.0
* Follow on minor releases branch-2.y off of branch-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Sean Busbey-2
In reply to this post by Josh Elser-2
On Wed, Jun 7, 2017 at 10:08 AM, Josh Elser <[hidden email]> wrote:

>
> On 6/7/17 11:04 AM, Josh Elser wrote:
>>
>>
>>
>> On 6/7/17 1:17 AM, Stack wrote:
>>>
>>> Lets start in on the hardening of hbase-2.0.0. All features are in though
>>> in need of test and polish. There are tasks outstanding around migration
>>> from hbase-1 to hbase-2 and narratives to tell our users around timeout,
>>> etc. We still need to update dependencies, revamp defaults, etc., but the
>>> hbase-2.0.0 countdown has started in earnest.
>>>
>>> I intend to cut an alpha in the next day or so just so folks can start
>>> kicking the tires even though we are a good ways from beta [1].
>>>
>>> To be clear, we are done w/ 'features' for hbase-2.0.0. Bug fixes and
>>> polish only please from here on out. If you have a borderline item or an
>>> item you just can't do w/o, lets discuss.
>>
>>
>> Yay, progress! Thanks for pushing, S.
>>
>>> I just set the version on master branch to be 3.0.0-SNAPSHOT.
>>
>>
>> I was just thinking about this one this morning: would master become 2.1.0
>> or 3.0.0?
>>
>> I'd guess that the intent is to put more emphasis on the "x" instead of
>> the "y" and "z" (for a version string "x.y.z")? We all on board with that
>> plan too, for better or for worse? :)
>
>
> Clarification: I'm really trying to ask the question, should we have a
> "branch-2.0" for tracking HBase-2.0.0 instead of a "branch-2"?
>
> I think trying to avoid multiple, concurrently developed 2.y release lines
> would help our sanity (do more 2.y.0 releases, fewer 2.y.z releases), but
> that would mean that we're consciously pushing towards a faster cadence for
> x.0.0 releases to come. If this is the case, "branch-2" makes sense;
> however, if the plan would be to stick with how HBase-1.y.z has been going,
> I'd expect a "branch-2.0" (and a "branch-2").

We're now officially replying past each other, so I'm going to slow down. :)

creating a branch-2 followed by a branch-2.0 when it's time for 2.0.0
gives us the same structure we have for brnach-1 releases, which IMHO
should be our default unless we have a larger community discussion
around release emphasis (and I don't think the 2.0 release process
should wait for said discusison; branches are cheap).

There's been some talk about how we can increase our minor release
cadence, but personally I really like how our RM strategy has helped
us keep a mostly-good cadence of maintenance releases.

Speaking as someone who's done the RM job, I view the maintenance
releases as mostly a herding cats exercise. I have to make sure jira
and git look sensible, periodically make sure the dummy-lights of our
builds.a.o jobs aren't flashing, and then turn the crank to grind
through the actual mechanics of a release candidate. If I was doing
that for minor releases instead, I'd feel compelled to do more cluster
based testing (like I did for the 1.2.0 release) and I don't think I
personally have time for that on an ongoing basis.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Josh Elser-2


On 6/7/17 11:15 AM, Sean Busbey wrote:

> On Wed, Jun 7, 2017 at 10:08 AM, Josh Elser <[hidden email]> wrote:
>>
>> On 6/7/17 11:04 AM, Josh Elser wrote:
>>>
>>>
>>>
>>> On 6/7/17 1:17 AM, Stack wrote:
>>>>
>>>> Lets start in on the hardening of hbase-2.0.0. All features are in though
>>>> in need of test and polish. There are tasks outstanding around migration
>>>> from hbase-1 to hbase-2 and narratives to tell our users around timeout,
>>>> etc. We still need to update dependencies, revamp defaults, etc., but the
>>>> hbase-2.0.0 countdown has started in earnest.
>>>>
>>>> I intend to cut an alpha in the next day or so just so folks can start
>>>> kicking the tires even though we are a good ways from beta [1].
>>>>
>>>> To be clear, we are done w/ 'features' for hbase-2.0.0. Bug fixes and
>>>> polish only please from here on out. If you have a borderline item or an
>>>> item you just can't do w/o, lets discuss.
>>>
>>>
>>> Yay, progress! Thanks for pushing, S.
>>>
>>>> I just set the version on master branch to be 3.0.0-SNAPSHOT.
>>>
>>>
>>> I was just thinking about this one this morning: would master become 2.1.0
>>> or 3.0.0?
>>>
>>> I'd guess that the intent is to put more emphasis on the "x" instead of
>>> the "y" and "z" (for a version string "x.y.z")? We all on board with that
>>> plan too, for better or for worse? :)
>>
>>
>> Clarification: I'm really trying to ask the question, should we have a
>> "branch-2.0" for tracking HBase-2.0.0 instead of a "branch-2"?
>>
>> I think trying to avoid multiple, concurrently developed 2.y release lines
>> would help our sanity (do more 2.y.0 releases, fewer 2.y.z releases), but
>> that would mean that we're consciously pushing towards a faster cadence for
>> x.0.0 releases to come. If this is the case, "branch-2" makes sense;
>> however, if the plan would be to stick with how HBase-1.y.z has been going,
>> I'd expect a "branch-2.0" (and a "branch-2").
>
> We're now officially replying past each other, so I'm going to slow down. :)

/me smiles

> creating a branch-2 followed by a branch-2.0 when it's time for 2.0.0
> gives us the same structure we have for brnach-1 releases, which IMHO
> should be our default unless we have a larger community discussion
> around release emphasis (and I don't think the 2.0 release process
> should wait for said discusison; branches are cheap).

Gotcha! Your other email (with the 4-5 steps) clarified this well.

> There's been some talk about how we can increase our minor release
> cadence, but personally I really like how our RM strategy has helped
> us keep a mostly-good cadence of maintenance releases.
>
> Speaking as someone who's done the RM job, I view the maintenance
> releases as mostly a herding cats exercise. I have to make sure jira
> and git look sensible, periodically make sure the dummy-lights of our
> builds.a.o jobs aren't flashing, and then turn the crank to grind
> through the actual mechanics of a release candidate. If I was doing
> that for minor releases instead, I'd feel compelled to do more cluster
> based testing (like I did for the 1.2.0 release) and I don't think I
> personally have time for that on an ongoing basis.

Understood. I just realized that I wasn't sure if the intention was for
HBase-2 releases to follow the same "train" as HBase-1 releases. Given
the struggle to just slow down master to make branch-2 was hard -- I
couldn't have said if there was a bigger goal ongoing to try to avoid
that for the eventual branch-3.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

stack-3
In reply to this post by Sean Busbey-2
On Wed, Jun 7, 2017 at 8:09 AM, Sean Busbey <[hidden email]> wrote:

I liked Josh's question on where is the hbase-2.0 branch and the reminder
on the Andrew suggestion that we shift release version emphasis left a
digit. Lets try it in hbase-2.


>
> Thinking about this more, did we document the branching strategy anywhere?
>
> Like, this is what I expect is going to happen, but it occurs to me
> that I can't point at why:
>
> * branch-2 made off of master
> * alpha/beta releases tagged off of branch-2
> * branch-2.0 made off of branch-2
> * 2.0.0 GA release tagged off of branch-2.0
> * Follow on minor releases branch-2.y off of branch-2
>

Nice writeup Sean. Thats my understanding. Shove it in the refguide? Give
it a day in case others think it different?

St.Ack
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Andrew Purtell
Thanks.
I'd like to see us RM branch-2, branch-1, and master and get away from
narrow focus on the branch-x.y branches that only produce patch releases.
Seems a better use of RM bandwidth to supervise a whole code line.

On Wed, Jun 7, 2017 at 9:52 AM, Stack <[hidden email]> wrote:

> On Wed, Jun 7, 2017 at 8:09 AM, Sean Busbey <[hidden email]> wrote:
>
> I liked Josh's question on where is the hbase-2.0 branch and the reminder
> on the Andrew suggestion that we shift release version emphasis left a
> digit. Lets try it in hbase-2.
>
>
> >
> > Thinking about this more, did we document the branching strategy
> anywhere?
> >
> > Like, this is what I expect is going to happen, but it occurs to me
> > that I can't point at why:
> >
> > * branch-2 made off of master
> > * alpha/beta releases tagged off of branch-2
> > * branch-2.0 made off of branch-2
> > * 2.0.0 GA release tagged off of branch-2.0
> > * Follow on minor releases branch-2.y off of branch-2
> >
>
> Nice writeup Sean. Thats my understanding. Shove it in the refguide? Give
> it a day in case others think it different?
>
> St.Ack
>



--
Best regards,

   - Andy

If you are given a choice, you believe you have acted freely. - Raymond
Teller (via Peter Watts)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

stack-3
On Wed, Jun 7, 2017 at 11:13 AM, Andrew Purtell <[hidden email]> wrote:

> Thanks.
> I'd like to see us RM branch-2, branch-1, and master and get away from
> narrow focus on the branch-x.y branches that only produce patch releases.
> Seems a better use of RM bandwidth to supervise a whole code line.
>
>
I like this idea. Lets try it.

Related, I just published 2.0.0-SNAPSHOT cut from branch-2. I'm thinking of
just putting this up as RC for 2.0.0-alpha1. Any objections? Would be good
to have something up even if it has wrong hadoop, wrong libs, is in
complete, etc.

St.Ack




> On Wed, Jun 7, 2017 at 9:52 AM, Stack <[hidden email]> wrote:
>
> > On Wed, Jun 7, 2017 at 8:09 AM, Sean Busbey <[hidden email]> wrote:
> >
> > I liked Josh's question on where is the hbase-2.0 branch and the reminder
> > on the Andrew suggestion that we shift release version emphasis left a
> > digit. Lets try it in hbase-2.
> >
> >
> > >
> > > Thinking about this more, did we document the branching strategy
> > anywhere?
> > >
> > > Like, this is what I expect is going to happen, but it occurs to me
> > > that I can't point at why:
> > >
> > > * branch-2 made off of master
> > > * alpha/beta releases tagged off of branch-2
> > > * branch-2.0 made off of branch-2
> > > * 2.0.0 GA release tagged off of branch-2.0
> > > * Follow on minor releases branch-2.y off of branch-2
> > >
> >
> > Nice writeup Sean. Thats my understanding. Shove it in the refguide? Give
> > it a day in case others think it different?
> >
> > St.Ack
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> If you are given a choice, you believe you have acted freely. - Raymond
> Teller (via Peter Watts)
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Jonathan Hsieh
+1 for 2.0.0-alpha1.  It would be really helpful for dependent projects
getting started against the updated apis (e.g. removed deprecated apis).

Jon

On Wed, Jun 7, 2017 at 12:31 PM, Stack <[hidden email]> wrote:

> On Wed, Jun 7, 2017 at 11:13 AM, Andrew Purtell <[hidden email]>
> wrote:
>
> > Thanks.
> > I'd like to see us RM branch-2, branch-1, and master and get away from
> > narrow focus on the branch-x.y branches that only produce patch releases.
> > Seems a better use of RM bandwidth to supervise a whole code line.
> >
> >
> I like this idea. Lets try it.
>
> Related, I just published 2.0.0-SNAPSHOT cut from branch-2. I'm thinking of
> just putting this up as RC for 2.0.0-alpha1. Any objections? Would be good
> to have something up even if it has wrong hadoop, wrong libs, is in
> complete, etc.
>
> St.Ack
>
>
>
>
> > On Wed, Jun 7, 2017 at 9:52 AM, Stack <[hidden email]> wrote:
> >
> > > On Wed, Jun 7, 2017 at 8:09 AM, Sean Busbey <[hidden email]> wrote:
> > >
> > > I liked Josh's question on where is the hbase-2.0 branch and the
> reminder
> > > on the Andrew suggestion that we shift release version emphasis left a
> > > digit. Lets try it in hbase-2.
> > >
> > >
> > > >
> > > > Thinking about this more, did we document the branching strategy
> > > anywhere?
> > > >
> > > > Like, this is what I expect is going to happen, but it occurs to me
> > > > that I can't point at why:
> > > >
> > > > * branch-2 made off of master
> > > > * alpha/beta releases tagged off of branch-2
> > > > * branch-2.0 made off of branch-2
> > > > * 2.0.0 GA release tagged off of branch-2.0
> > > > * Follow on minor releases branch-2.y off of branch-2
> > > >
> > >
> > > Nice writeup Sean. Thats my understanding. Shove it in the refguide?
> Give
> > > it a day in case others think it different?
> > >
> > > St.Ack
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > If you are given a choice, you believe you have acted freely. - Raymond
> > Teller (via Peter Watts)
> >
>



--
// Jonathan Hsieh (shay)
// HBase Team, Engineering Manager, Cloudera
// [hidden email] // @jmhsieh
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

stack-3
On Wed, Jun 7, 2017 at 1:19 PM, Jonathan Hsieh <[hidden email]> wrote:

> +1 for 2.0.0-alpha1.  It would be really helpful for dependent projects
> getting started against the updated apis (e.g. removed deprecated apis).
>
>
Let me push up a rough cut as an RC. Lets see how we do.
St.Ack



> Jon
>
> On Wed, Jun 7, 2017 at 12:31 PM, Stack <[hidden email]> wrote:
>
> > On Wed, Jun 7, 2017 at 11:13 AM, Andrew Purtell <[hidden email]>
> > wrote:
> >
> > > Thanks.
> > > I'd like to see us RM branch-2, branch-1, and master and get away from
> > > narrow focus on the branch-x.y branches that only produce patch
> releases.
> > > Seems a better use of RM bandwidth to supervise a whole code line.
> > >
> > >
> > I like this idea. Lets try it.
> >
> > Related, I just published 2.0.0-SNAPSHOT cut from branch-2. I'm thinking
> of
> > just putting this up as RC for 2.0.0-alpha1. Any objections? Would be
> good
> > to have something up even if it has wrong hadoop, wrong libs, is in
> > complete, etc.
> >
> > St.Ack
> >
> >
> >
> >
> > > On Wed, Jun 7, 2017 at 9:52 AM, Stack <[hidden email]> wrote:
> > >
> > > > On Wed, Jun 7, 2017 at 8:09 AM, Sean Busbey <[hidden email]>
> wrote:
> > > >
> > > > I liked Josh's question on where is the hbase-2.0 branch and the
> > reminder
> > > > on the Andrew suggestion that we shift release version emphasis left
> a
> > > > digit. Lets try it in hbase-2.
> > > >
> > > >
> > > > >
> > > > > Thinking about this more, did we document the branching strategy
> > > > anywhere?
> > > > >
> > > > > Like, this is what I expect is going to happen, but it occurs to me
> > > > > that I can't point at why:
> > > > >
> > > > > * branch-2 made off of master
> > > > > * alpha/beta releases tagged off of branch-2
> > > > > * branch-2.0 made off of branch-2
> > > > > * 2.0.0 GA release tagged off of branch-2.0
> > > > > * Follow on minor releases branch-2.y off of branch-2
> > > > >
> > > >
> > > > Nice writeup Sean. Thats my understanding. Shove it in the refguide?
> > Give
> > > > it a day in case others think it different?
> > > >
> > > > St.Ack
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > If you are given a choice, you believe you have acted freely. - Raymond
> > > Teller (via Peter Watts)
> > >
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // HBase Team, Engineering Manager, Cloudera
> // [hidden email] // @jmhsieh
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Enis Söztutar
Above plan:
* branch-2 made off of master
* alpha/beta releases tagged off of branch-2
* branch-2.0 made off of branch-2
* 2.0.0 GA release tagged off of branch-2.0
* Follow on minor releases branch-2.y off of branch-2

Looks good. That is what we have done for 1.0/branch-1 as well. The only
thing is that branch-2.0 can be delayed up until after the actual release.
No need to maintain another branch, unless 2.0 happened, and there is a
need for differentiating between 2.0.0 and 2.1.0.

Also +1 on the alpha1 release. Good to have some release out to test out
the release mechanics.

Enis




On Wed, Jun 7, 2017 at 2:41 PM, Stack <[hidden email]> wrote:

> On Wed, Jun 7, 2017 at 1:19 PM, Jonathan Hsieh <[hidden email]> wrote:
>
> > +1 for 2.0.0-alpha1.  It would be really helpful for dependent projects
> > getting started against the updated apis (e.g. removed deprecated apis).
> >
> >
> Let me push up a rough cut as an RC. Lets see how we do.
> St.Ack
>
>
>
> > Jon
> >
> > On Wed, Jun 7, 2017 at 12:31 PM, Stack <[hidden email]> wrote:
> >
> > > On Wed, Jun 7, 2017 at 11:13 AM, Andrew Purtell <[hidden email]>
> > > wrote:
> > >
> > > > Thanks.
> > > > I'd like to see us RM branch-2, branch-1, and master and get away
> from
> > > > narrow focus on the branch-x.y branches that only produce patch
> > releases.
> > > > Seems a better use of RM bandwidth to supervise a whole code line.
> > > >
> > > >
> > > I like this idea. Lets try it.
> > >
> > > Related, I just published 2.0.0-SNAPSHOT cut from branch-2. I'm
> thinking
> > of
> > > just putting this up as RC for 2.0.0-alpha1. Any objections? Would be
> > good
> > > to have something up even if it has wrong hadoop, wrong libs, is in
> > > complete, etc.
> > >
> > > St.Ack
> > >
> > >
> > >
> > >
> > > > On Wed, Jun 7, 2017 at 9:52 AM, Stack <[hidden email]> wrote:
> > > >
> > > > > On Wed, Jun 7, 2017 at 8:09 AM, Sean Busbey <[hidden email]>
> > wrote:
> > > > >
> > > > > I liked Josh's question on where is the hbase-2.0 branch and the
> > > reminder
> > > > > on the Andrew suggestion that we shift release version emphasis
> left
> > a
> > > > > digit. Lets try it in hbase-2.
> > > > >
> > > > >
> > > > > >
> > > > > > Thinking about this more, did we document the branching strategy
> > > > > anywhere?
> > > > > >
> > > > > > Like, this is what I expect is going to happen, but it occurs to
> me
> > > > > > that I can't point at why:
> > > > > >
> > > > > > * branch-2 made off of master
> > > > > > * alpha/beta releases tagged off of branch-2
> > > > > > * branch-2.0 made off of branch-2
> > > > > > * 2.0.0 GA release tagged off of branch-2.0
> > > > > > * Follow on minor releases branch-2.y off of branch-2
> > > > > >
> > > > >
> > > > > Nice writeup Sean. Thats my understanding. Shove it in the
> refguide?
> > > Give
> > > > > it a day in case others think it different?
> > > > >
> > > > > St.Ack
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >
> > > >    - Andy
> > > >
> > > > If you are given a choice, you believe you have acted freely. -
> Raymond
> > > > Teller (via Peter Watts)
> > > >
> > >
> >
> >
> >
> > --
> > // Jonathan Hsieh (shay)
> > // HBase Team, Engineering Manager, Cloudera
> > // [hidden email] // @jmhsieh
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0

Sean Busbey-2
In reply to this post by stack-3
On Wed, Jun 7, 2017 at 2:31 PM, Stack <[hidden email]> wrote:

> On Wed, Jun 7, 2017 at 11:13 AM, Andrew Purtell <[hidden email]> wrote:
>
>> Thanks.
>> I'd like to see us RM branch-2, branch-1, and master and get away from
>> narrow focus on the branch-x.y branches that only produce patch releases.
>> Seems a better use of RM bandwidth to supervise a whole code line.
>>
>>
> I like this idea. Lets try it.
>
> Related, I just published 2.0.0-SNAPSHOT cut from branch-2. I'm thinking of
> just putting this up as RC for 2.0.0-alpha1. Any objections? Would be good
> to have something up even if it has wrong hadoop, wrong libs, is in
> complete, etc.
>
> St.Ack


So long as we're consistent in messaging to downstream, sounds good to me.

Addressable artifacts would let me e.g. update hbase-downstreamer and
ycsb, which would make testing easier.
Loading...