You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@hbase.apache.org by Sean Busbey <bu...@cloudera.com> on 2015/02/27 19:06:28 UTC

Minor release cadence for branch-1

Hey folks!

Apologies if I've overlooked this getting discussed already. Do we have a
goal release cadence for minor versions out of branch-1?

My first gut reaction is that it should essentially match the cadence we've
been aiming at for the 0.98 line. That would mean attempting to match
monthly, I think?

The obvious problem with this is that now that we have patch versions, it
means essentially getting a new branch per month for backports. That's
quickly going to get old, even if we presume most additions will move onto
branch-2 in a year or so.

What do folks think about limiting which minor versions patch-level fixes
go into? We could default to the most recent release + current minor dev
and go back farther when requested by the issue filer?

That means in ~3 months we'd expect branch-1 to be working on 1.4 and most
patch-level fixes to go into branch-1.3 and branch-1. If someone reported a
failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1 and
branch-1.2.

Or should we just stick with hitting all of the branches on the presumption
that the cherry picks should be trivial?

-- 
Sean

Re: Minor release cadence for branch-1

Posted by Andrew Purtell <ap...@apache.org>.

Not 6 years :-)

On Fri, Mar 6, 2015 at 2:54 PM, Stack <st...@duboce.net> wrote:

> On Fri, Mar 6, 2015 at 2:27 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > I think we can manage. The nice thing about on demand minors is what
> > emerges will be driven by actual need. For example after we move up from
> > 0.98 to 1.x, I might want to RM a minor line that corresponds to our
> > production. Someone working for a vendor might be RMing a minor line
> > corresponding to the latest release. The number of active lines will be
> > bounded by the level of available interest and effort in maintaining
> them.
> >
> >
> Agree. Patch releases on roughly monthly would be sweet. I think a
> 'natural' minor cadence will emerge.
>
> 2.0 in 6 months or 6 years?
>
> St.Ack
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Minor release cadence for branch-1

Posted by Stack <st...@duboce.net>.

On Fri, Mar 6, 2015 at 2:27 PM, Andrew Purtell <ap...@apache.org> wrote:

> I think we can manage. The nice thing about on demand minors is what
> emerges will be driven by actual need. For example after we move up from
> 0.98 to 1.x, I might want to RM a minor line that corresponds to our
> production. Someone working for a vendor might be RMing a minor line
> corresponding to the latest release. The number of active lines will be
> bounded by the level of available interest and effort in maintaining them.
>
>
Agree. Patch releases on roughly monthly would be sweet. I think a
'natural' minor cadence will emerge.

2.0 in 6 months or 6 years?

St.Ack

Re: Minor release cadence for branch-1

Posted by Andrew Purtell <ap...@apache.org>.

I think we can manage. The nice thing about on demand minors is what
emerges will be driven by actual need. For example after we move up from
0.98 to 1.x, I might want to RM a minor line that corresponds to our
production. Someone working for a vendor might be RMing a minor line
corresponding to the latest release. The number of active lines will be
bounded by the level of available interest and effort in maintaining them.


On Thu, Mar 5, 2015 at 5:04 PM, Enis Söztutar <en...@gmail.com> wrote:

> +1 doing patch releases more frequently, and doing minor releases on a
> per-need basis and if an RM volunteers to drive a minor version.
>
> Every minor release we do will come up with its own branch, and we might
> end up with a lot of active branches to accept bug fixes which might put
> some burden on the committers to check in to so many branches.
>
> Enis
>
> On Thu, Mar 5, 2015 at 1:04 PM, lars hofhansl <la...@apache.org> wrote:
>
> > I'd say as long as there are folks who contribute patches we can do patch
> > releases for older minor releases. It's open source :)
> >
> > Keeping *all* minor releases alive seem onerous (there could be dozens -
> > unless we significantly drive down the time between major releases).Could
> > do the Linux model and support some minor versions a bit longer than
> others.
> > Putting myself in Salesforce's (where I work) shoes... We'd move from
> > minor or patch release to the next at our own pace. On a case-by-case
> basis
> > we'd decide whether to deploy a patch release, wait a bit, or move to the
> > next minor release.HBase is nicely managed in terms of stability and
> > compatability, so as along as minor releases are rolling upgradable (with
> > some versions skipped - i.e. we could go from (say) 1.1.2 to 1.2.7) we'd
> > likely be following the minor versions mostly.
> > We would *very* rarely switch major-version as client-server
> > incompatibilities are very hard to handle for us.I don't think as far as
> > big shops go we're very special...?
> >
> > Maybe we'd have to play this by ear... Start making new minor versions,
> > and see how much work it is to maintain the older ones and what our users
> > end up doing (staying on a minor version or adopting new minor versions).
> >
> > This is a very interesting topic.
> >
> > -- Lars
> >
> >       From: Sean Busbey <bu...@cloudera.com>
> >  To: dev <de...@hbase.apache.org>
> > Cc: lars hofhansl <la...@apache.org>
> >  Sent: Thursday, March 5, 2015 12:48 PM
> >  Subject: Re: Minor release cadence for branch-1
> >
> > It sounds to me like we have consensus around monthly for patch releases
> > and minor releases on demand, provided we can find RMs.
> >
> > Would it be reasonable to keep all the minor release lines active until
> we
> > have a newer major release? At that point we could keep just the most
> > recent minor release going so long as there's demand.
> >
> > --
> > Sean
> >
> >
> > On Mar 5, 2015 2:23 PM, "lars hofhansl" <la...@apache.org> wrote:
> >
> > > Any further comments on this?
> > > Seems important to get agreement at least generally.
> > > -- Lars
> > >      From: lars hofhansl <la...@apache.org>
> > >  To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> > >  Sent: Monday, March 2, 2015 10:26 PM
> > >  Subject: Re: Minor release cadence for branch-1
> > >
> > > Hmmm...
> > >
> > > I had only expect a monthly patch cadence for minor release (btw, we
> > > started monthly releases with 0.94.x).
> > >
> > > In 0.94 and 0.98 we had no clear distinction between patch and minor
> > > releases.
> > >
> > > For minor releases it seems an on-demand model is more what we want.
> I.e.
> > > we'd have a monthly 1.0.1, 1.0.2, etc. Then at some point we'd release
> > > 1.1.0... "when it's ready".
> > > Since that's a minor upgrade we can then have a few more 1.0.x releases
> > > (like 0.94 is now) and then tell folks to upgrade to 1.1.x.
> > > (in the end, though, patch releases should continue as long as folks
> are
> > > willing to contribute patches)
> > >
> > > I'd be happy to sign up to do a few minor (1.1, 1.2, or whatever)
> > releases
> > > - but I do think we should share the love not have the same folks do
> > > multiple releases simulataneously.
> > >
> > > -- Lars
> > >
> > >
> > >      From: Sean Busbey <bu...@cloudera.com>
> > >
> > >
> > >  To: dev <de...@hbase.apache.org>
> > >  Sent: Friday, February 27, 2015 10:06 AM
> > >  Subject: Minor release cadence for branch-1
> > >
> > > Hey folks!
> > >
> > > Apologies if I've overlooked this getting discussed already. Do we
> have a
> > > goal release cadence for minor versions out of branch-1?
> > >
> > > My first gut reaction is that it should essentially match the cadence
> > we've
> > > been aiming at for the 0.98 line. That would mean attempting to match
> > > monthly, I think?
> > >
> > > The obvious problem with this is that now that we have patch versions,
> it
> > > means essentially getting a new branch per month for backports. That's
> > > quickly going to get old, even if we presume most additions will move
> > onto
> > > branch-2 in a year or so.
> > >
> > > What do folks think about limiting which minor versions patch-level
> fixes
> > > go into? We could default to the most recent release + current minor
> dev
> > > and go back farther when requested by the issue filer?
> > >
> > > That means in ~3 months we'd expect branch-1 to be working on 1.4 and
> > most
> > > patch-level fixes to go into branch-1.3 and branch-1. If someone
> > reported a
> > > failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1
> > and
> > > branch-1.2.
> > >
> > > Or should we just stick with hitting all of the branches on the
> > presumption
> > > that the cherry picks should be trivial?
> > >
> > > --
> > > Sean
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Minor release cadence for branch-1

Posted by Enis Söztutar <en...@gmail.com>.

+1 doing patch releases more frequently, and doing minor releases on a
per-need basis and if an RM volunteers to drive a minor version.

Every minor release we do will come up with its own branch, and we might
end up with a lot of active branches to accept bug fixes which might put
some burden on the committers to check in to so many branches.

Enis

On Thu, Mar 5, 2015 at 1:04 PM, lars hofhansl <la...@apache.org> wrote:

> I'd say as long as there are folks who contribute patches we can do patch
> releases for older minor releases. It's open source :)
>
> Keeping *all* minor releases alive seem onerous (there could be dozens -
> unless we significantly drive down the time between major releases).Could
> do the Linux model and support some minor versions a bit longer than others.
> Putting myself in Salesforce's (where I work) shoes... We'd move from
> minor or patch release to the next at our own pace. On a case-by-case basis
> we'd decide whether to deploy a patch release, wait a bit, or move to the
> next minor release.HBase is nicely managed in terms of stability and
> compatability, so as along as minor releases are rolling upgradable (with
> some versions skipped - i.e. we could go from (say) 1.1.2 to 1.2.7) we'd
> likely be following the minor versions mostly.
> We would *very* rarely switch major-version as client-server
> incompatibilities are very hard to handle for us.I don't think as far as
> big shops go we're very special...?
>
> Maybe we'd have to play this by ear... Start making new minor versions,
> and see how much work it is to maintain the older ones and what our users
> end up doing (staying on a minor version or adopting new minor versions).
>
> This is a very interesting topic.
>
> -- Lars
>
>       From: Sean Busbey <bu...@cloudera.com>
>  To: dev <de...@hbase.apache.org>
> Cc: lars hofhansl <la...@apache.org>
>  Sent: Thursday, March 5, 2015 12:48 PM
>  Subject: Re: Minor release cadence for branch-1
>
> It sounds to me like we have consensus around monthly for patch releases
> and minor releases on demand, provided we can find RMs.
>
> Would it be reasonable to keep all the minor release lines active until we
> have a newer major release? At that point we could keep just the most
> recent minor release going so long as there's demand.
>
> --
> Sean
>
>
> On Mar 5, 2015 2:23 PM, "lars hofhansl" <la...@apache.org> wrote:
>
> > Any further comments on this?
> > Seems important to get agreement at least generally.
> > -- Lars
> >      From: lars hofhansl <la...@apache.org>
> >  To: "dev@hbase.apache.org" <de...@hbase.apache.org>
> >  Sent: Monday, March 2, 2015 10:26 PM
> >  Subject: Re: Minor release cadence for branch-1
> >
> > Hmmm...
> >
> > I had only expect a monthly patch cadence for minor release (btw, we
> > started monthly releases with 0.94.x).
> >
> > In 0.94 and 0.98 we had no clear distinction between patch and minor
> > releases.
> >
> > For minor releases it seems an on-demand model is more what we want. I.e.
> > we'd have a monthly 1.0.1, 1.0.2, etc. Then at some point we'd release
> > 1.1.0... "when it's ready".
> > Since that's a minor upgrade we can then have a few more 1.0.x releases
> > (like 0.94 is now) and then tell folks to upgrade to 1.1.x.
> > (in the end, though, patch releases should continue as long as folks are
> > willing to contribute patches)
> >
> > I'd be happy to sign up to do a few minor (1.1, 1.2, or whatever)
> releases
> > - but I do think we should share the love not have the same folks do
> > multiple releases simulataneously.
> >
> > -- Lars
> >
> >
> >      From: Sean Busbey <bu...@cloudera.com>
> >
> >
> >  To: dev <de...@hbase.apache.org>
> >  Sent: Friday, February 27, 2015 10:06 AM
> >  Subject: Minor release cadence for branch-1
> >
> > Hey folks!
> >
> > Apologies if I've overlooked this getting discussed already. Do we have a
> > goal release cadence for minor versions out of branch-1?
> >
> > My first gut reaction is that it should essentially match the cadence
> we've
> > been aiming at for the 0.98 line. That would mean attempting to match
> > monthly, I think?
> >
> > The obvious problem with this is that now that we have patch versions, it
> > means essentially getting a new branch per month for backports. That's
> > quickly going to get old, even if we presume most additions will move
> onto
> > branch-2 in a year or so.
> >
> > What do folks think about limiting which minor versions patch-level fixes
> > go into? We could default to the most recent release + current minor dev
> > and go back farther when requested by the issue filer?
> >
> > That means in ~3 months we'd expect branch-1 to be working on 1.4 and
> most
> > patch-level fixes to go into branch-1.3 and branch-1. If someone
> reported a
> > failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1
> and
> > branch-1.2.
> >
> > Or should we just stick with hitting all of the branches on the
> presumption
> > that the cherry picks should be trivial?
> >
> > --
> > Sean
> >
> >
> >
> >
> >
>
>
>
>

Re: Minor release cadence for branch-1

Posted by lars hofhansl <la...@apache.org>.

I'd say as long as there are folks who contribute patches we can do patch releases for older minor releases. It's open source :)

Keeping *all* minor releases alive seem onerous (there could be dozens - unless we significantly drive down the time between major releases).Could do the Linux model and support some minor versions a bit longer than others.
Putting myself in Salesforce's (where I work) shoes... We'd move from minor or patch release to the next at our own pace. On a case-by-case basis we'd decide whether to deploy a patch release, wait a bit, or move to the next minor release.HBase is nicely managed in terms of stability and compatability, so as along as minor releases are rolling upgradable (with some versions skipped - i.e. we could go from (say) 1.1.2 to 1.2.7) we'd likely be following the minor versions mostly.
We would *very* rarely switch major-version as client-server incompatibilities are very hard to handle for us.I don't think as far as big shops go we're very special...?

Maybe we'd have to play this by ear... Start making new minor versions, and see how much work it is to maintain the older ones and what our users end up doing (staying on a minor version or adopting new minor versions).

This is a very interesting topic.

-- Lars

      From: Sean Busbey <bu...@cloudera.com>
 To: dev <de...@hbase.apache.org> 
Cc: lars hofhansl <la...@apache.org> 
 Sent: Thursday, March 5, 2015 12:48 PM
 Subject: Re: Minor release cadence for branch-1

It sounds to me like we have consensus around monthly for patch releases
and minor releases on demand, provided we can find RMs.

Would it be reasonable to keep all the minor release lines active until we
have a newer major release? At that point we could keep just the most
recent minor release going so long as there's demand.

-- 
Sean

On Mar 5, 2015 2:23 PM, "lars hofhansl" <la...@apache.org> wrote:

> Any further comments on this?
> Seems important to get agreement at least generally.
> -- Lars
>      From: lars hofhansl <la...@apache.org>
>  To: "dev@hbase.apache.org" <de...@hbase.apache.org>
>  Sent: Monday, March 2, 2015 10:26 PM
>  Subject: Re: Minor release cadence for branch-1
>
> Hmmm...
>
> I had only expect a monthly patch cadence for minor release (btw, we
> started monthly releases with 0.94.x).
>
> In 0.94 and 0.98 we had no clear distinction between patch and minor
> releases.
>
> For minor releases it seems an on-demand model is more what we want. I.e.
> we'd have a monthly 1.0.1, 1.0.2, etc. Then at some point we'd release
> 1.1.0... "when it's ready".
> Since that's a minor upgrade we can then have a few more 1.0.x releases
> (like 0.94 is now) and then tell folks to upgrade to 1.1.x.
> (in the end, though, patch releases should continue as long as folks are
> willing to contribute patches)
>
> I'd be happy to sign up to do a few minor (1.1, 1.2, or whatever) releases
> - but I do think we should share the love not have the same folks do
> multiple releases simulataneously.
>
> -- Lars
>
>
>      From: Sean Busbey <bu...@cloudera.com>
>
>
>  To: dev <de...@hbase.apache.org>
>  Sent: Friday, February 27, 2015 10:06 AM
>  Subject: Minor release cadence for branch-1
>
> Hey folks!
>
> Apologies if I've overlooked this getting discussed already. Do we have a
> goal release cadence for minor versions out of branch-1?
>
> My first gut reaction is that it should essentially match the cadence we've
> been aiming at for the 0.98 line. That would mean attempting to match
> monthly, I think?
>
> The obvious problem with this is that now that we have patch versions, it
> means essentially getting a new branch per month for backports. That's
> quickly going to get old, even if we presume most additions will move onto
> branch-2 in a year or so.
>
> What do folks think about limiting which minor versions patch-level fixes
> go into? We could default to the most recent release + current minor dev
> and go back farther when requested by the issue filer?
>
> That means in ~3 months we'd expect branch-1 to be working on 1.4 and most
> patch-level fixes to go into branch-1.3 and branch-1. If someone reported a
> failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1 and
> branch-1.2.
>
> Or should we just stick with hitting all of the branches on the presumption
> that the cherry picks should be trivial?
>
> --
> Sean
>
>
>
>
>

Re: Minor release cadence for branch-1

Posted by Sean Busbey <bu...@cloudera.com>.

It sounds to me like we have consensus around monthly for patch releases
and minor releases on demand, provided we can find RMs.

Would it be reasonable to keep all the minor release lines active until we
have a newer major release? At that point we could keep just the most
recent minor release going so long as there's demand.

-- 
Sean
On Mar 5, 2015 2:23 PM, "lars hofhansl" <la...@apache.org> wrote:

> Any further comments on this?
> Seems important to get agreement at least generally.
> -- Lars
>       From: lars hofhansl <la...@apache.org>
>  To: "dev@hbase.apache.org" <de...@hbase.apache.org>
>  Sent: Monday, March 2, 2015 10:26 PM
>  Subject: Re: Minor release cadence for branch-1
>
> Hmmm...
>
> I had only expect a monthly patch cadence for minor release (btw, we
> started monthly releases with 0.94.x).
>
> In 0.94 and 0.98 we had no clear distinction between patch and minor
> releases.
>
> For minor releases it seems an on-demand model is more what we want. I.e.
> we'd have a monthly 1.0.1, 1.0.2, etc. Then at some point we'd release
> 1.1.0... "when it's ready".
> Since that's a minor upgrade we can then have a few more 1.0.x releases
> (like 0.94 is now) and then tell folks to upgrade to 1.1.x.
> (in the end, though, patch releases should continue as long as folks are
> willing to contribute patches)
>
> I'd be happy to sign up to do a few minor (1.1, 1.2, or whatever) releases
> - but I do think we should share the love not have the same folks do
> multiple releases simulataneously.
>
> -- Lars
>
>
>       From: Sean Busbey <bu...@cloudera.com>
>
>
>  To: dev <de...@hbase.apache.org>
>  Sent: Friday, February 27, 2015 10:06 AM
>  Subject: Minor release cadence for branch-1
>
> Hey folks!
>
> Apologies if I've overlooked this getting discussed already. Do we have a
> goal release cadence for minor versions out of branch-1?
>
> My first gut reaction is that it should essentially match the cadence we've
> been aiming at for the 0.98 line. That would mean attempting to match
> monthly, I think?
>
> The obvious problem with this is that now that we have patch versions, it
> means essentially getting a new branch per month for backports. That's
> quickly going to get old, even if we presume most additions will move onto
> branch-2 in a year or so.
>
> What do folks think about limiting which minor versions patch-level fixes
> go into? We could default to the most recent release + current minor dev
> and go back farther when requested by the issue filer?
>
> That means in ~3 months we'd expect branch-1 to be working on 1.4 and most
> patch-level fixes to go into branch-1.3 and branch-1. If someone reported a
> failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1 and
> branch-1.2.
>
> Or should we just stick with hitting all of the branches on the presumption
> that the cherry picks should be trivial?
>
> --
> Sean
>
>
>
>
>

Re: Minor release cadence for branch-1

Posted by lars hofhansl <la...@apache.org>.

Any further comments on this?
Seems important to get agreement at least generally.
-- Lars
From: lars hofhansl <la...@apache.org>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
Sent: Monday, March 2, 2015 10:26 PM
Subject: Re: Minor release cadence for branch-1

Hmmm...

I had only expect a monthly patch cadence for minor release (btw, we started monthly releases with 0.94.x).

In 0.94 and 0.98 we had no clear distinction between patch and minor releases.

For minor releases it seems an on-demand model is more what we want. I.e. we'd have a monthly 1.0.1, 1.0.2, etc. Then at some point we'd release 1.1.0... "when it's ready".
Since that's a minor upgrade we can then have a few more 1.0.x releases (like 0.94 is now) and then tell folks to upgrade to 1.1.x.
(in the end, though, patch releases should continue as long as folks are willing to contribute patches)

I'd be happy to sign up to do a few minor (1.1, 1.2, or whatever) releases - but I do think we should share the love not have the same folks do multiple releases simulataneously.

-- Lars

From: Sean Busbey <bu...@cloudera.com>

To: dev <de...@hbase.apache.org>
Sent: Friday, February 27, 2015 10:06 AM
Subject: Minor release cadence for branch-1
Hey folks!

Apologies if I've overlooked this getting discussed already. Do we have a
goal release cadence for minor versions out of branch-1?

My first gut reaction is that it should essentially match the cadence we've
been aiming at for the 0.98 line. That would mean attempting to match
monthly, I think?

The obvious problem with this is that now that we have patch versions, it
means essentially getting a new branch per month for backports. That's
quickly going to get old, even if we presume most additions will move onto
branch-2 in a year or so.

What do folks think about limiting which minor versions patch-level fixes
go into? We could default to the most recent release + current minor dev
and go back farther when requested by the issue filer?

That means in ~3 months we'd expect branch-1 to be working on 1.4 and most
patch-level fixes to go into branch-1.3 and branch-1. If someone reported a
failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1 and
branch-1.2.

Or should we just stick with hitting all of the branches on the presumption
that the cherry picks should be trivial?

--
Sean

Re: Minor release cadence for branch-1

Posted by lars hofhansl <la...@apache.org>.

Hmmm...

I had only expect a monthly patch cadence for minor release (btw, we started monthly releases with 0.94.x).

In 0.94 and 0.98 we had no clear distinction between patch and minor releases.

I'd be happy to sign up to do a few minor (1.1, 1.2, or whatever) releases - but I do think we should share the love not have the same folks do multiple releases simulataneously.

-- Lars

From: Sean Busbey <bu...@cloudera.com>
To: dev <de...@hbase.apache.org>
Sent: Friday, February 27, 2015 10:06 AM
Subject: Minor release cadence for branch-1

Hey folks!

Apologies if I've overlooked this getting discussed already. Do we have a
goal release cadence for minor versions out of branch-1?

My first gut reaction is that it should essentially match the cadence we've
been aiming at for the 0.98 line. That would mean attempting to match
monthly, I think?

Or should we just stick with hitting all of the branches on the presumption
that the cherry picks should be trivial?

--
Sean

Re: Minor release cadence for branch-1

Posted by Enis Söztutar <en...@gmail.com>.

I am planning on sticking to monthly release candidates for the 1.0.x
series of releases. The patches are somewhat controlled, so testing should
not be a huge effort.

However, 1.x series are expected to contain new features, and much more
change (1.1 already contains some big features on top of 1.0). Thus testing
at scale becomes really important before the release. Also my experience is
that:

1. People do not upgrade their HBase that frequently. This is expected,
since it is a database after all, we are not a library.
2. Testing the release candidate is A LOT of work. I would rather have less
number of better tested minor releases.

Monthly minor releases will be too much effort IMO. However, upgrading
patch versions 1.x.y -> 1.x.z should be a relatively "safe" option, so more
frequent patch releases makes sense.

My current understanding is that if a new feature lands in master, there is
no reason to not bring it to 1.x branches other than (1) the feature is not
BC according to semver. (2) the release branch for the next 1.x is not cut
yet (which is a timing issue), (3) the feature is not stable enough for
1.x.

Enis

On Fri, Feb 27, 2015 at 10:36 AM, Andrew Purtell <ap...@apache.org>
wrote:

> I would volunteer to RM a 1.1 line should we want one. See the discussion
> on HBASE-12972 and HBASE-12975 for some motivation in that respect. There
> are some supportable interfaces we are working on to make life easier for
> both HBase and Phoenix developers going forward that missed 1.0.0 and
> probably will need to start life in 1.1.0.
>
>
> On Fri, Feb 27, 2015 at 10:33 AM, Nick Dimiduk <nd...@gmail.com> wrote:
>
> > I don't think we have enough release managers or enough bandwidth as a
> > community to evaluate RC's for a monthly minor release cycle. My
> > understanding was that we'd continue doing patch releases on the monthly
> > cycle (RM's willing) and spin minor releases as we have new RM's
> volunteer.
> > I don't think we've had a discussion about how long we'd like a minor
> > release to stay active in the post-1.0 world, so this is a good topic to
> > broach.
> >
> > That is, of course, unless Enis signed up to RM the whole 1.x release
> > lifecycle. In which case, he has right of first refusal on the whole
> > line. That was not my understanding, however.
> >
> > -n
> >
> > On Friday, February 27, 2015, Sean Busbey <bu...@cloudera.com> wrote:
> >
> > > Hey folks!
> > >
> > > Apologies if I've overlooked this getting discussed already. Do we
> have a
> > > goal release cadence for minor versions out of branch-1?
> > >
> > > My first gut reaction is that it should essentially match the cadence
> > we've
> > > been aiming at for the 0.98 line. That would mean attempting to match
> > > monthly, I think?
> > >
> > > The obvious problem with this is that now that we have patch versions,
> it
> > > means essentially getting a new branch per month for backports. That's
> > > quickly going to get old, even if we presume most additions will move
> > onto
> > > branch-2 in a year or so.
> > >
> > > What do folks think about limiting which minor versions patch-level
> fixes
> > > go into? We could default to the most recent release + current minor
> dev
> > > and go back farther when requested by the issue filer?
> > >
> > > That means in ~3 months we'd expect branch-1 to be working on 1.4 and
> > most
> > > patch-level fixes to go into branch-1.3 and branch-1. If someone
> > reported a
> > > failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1
> > and
> > > branch-1.2.
> > >
> > > Or should we just stick with hitting all of the branches on the
> > presumption
> > > that the cherry picks should be trivial?
> > >
> > > --
> > > Sean
> > >
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

Re: Minor release cadence for branch-1

Posted by Andrew Purtell <ap...@apache.org>.

I would volunteer to RM a 1.1 line should we want one. See the discussion
on HBASE-12972 and HBASE-12975 for some motivation in that respect. There
are some supportable interfaces we are working on to make life easier for
both HBase and Phoenix developers going forward that missed 1.0.0 and
probably will need to start life in 1.1.0.


On Fri, Feb 27, 2015 at 10:33 AM, Nick Dimiduk <nd...@gmail.com> wrote:

> I don't think we have enough release managers or enough bandwidth as a
> community to evaluate RC's for a monthly minor release cycle. My
> understanding was that we'd continue doing patch releases on the monthly
> cycle (RM's willing) and spin minor releases as we have new RM's volunteer.
> I don't think we've had a discussion about how long we'd like a minor
> release to stay active in the post-1.0 world, so this is a good topic to
> broach.
>
> That is, of course, unless Enis signed up to RM the whole 1.x release
> lifecycle. In which case, he has right of first refusal on the whole
> line. That was not my understanding, however.
>
> -n
>
> On Friday, February 27, 2015, Sean Busbey <bu...@cloudera.com> wrote:
>
> > Hey folks!
> >
> > Apologies if I've overlooked this getting discussed already. Do we have a
> > goal release cadence for minor versions out of branch-1?
> >
> > My first gut reaction is that it should essentially match the cadence
> we've
> > been aiming at for the 0.98 line. That would mean attempting to match
> > monthly, I think?
> >
> > The obvious problem with this is that now that we have patch versions, it
> > means essentially getting a new branch per month for backports. That's
> > quickly going to get old, even if we presume most additions will move
> onto
> > branch-2 in a year or so.
> >
> > What do folks think about limiting which minor versions patch-level fixes
> > go into? We could default to the most recent release + current minor dev
> > and go back farther when requested by the issue filer?
> >
> > That means in ~3 months we'd expect branch-1 to be working on 1.4 and
> most
> > patch-level fixes to go into branch-1.3 and branch-1. If someone
> reported a
> > failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1
> and
> > branch-1.2.
> >
> > Or should we just stick with hitting all of the branches on the
> presumption
> > that the cherry picks should be trivial?
> >
> > --
> > Sean
> >
>



-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: Minor release cadence for branch-1

Posted by Nick Dimiduk <nd...@gmail.com>.

I don't think we have enough release managers or enough bandwidth as a
community to evaluate RC's for a monthly minor release cycle. My
understanding was that we'd continue doing patch releases on the monthly
cycle (RM's willing) and spin minor releases as we have new RM's volunteer.
I don't think we've had a discussion about how long we'd like a minor
release to stay active in the post-1.0 world, so this is a good topic to
broach.

That is, of course, unless Enis signed up to RM the whole 1.x release
lifecycle. In which case, he has right of first refusal on the whole
line. That was not my understanding, however.

-n

On Friday, February 27, 2015, Sean Busbey <bu...@cloudera.com> wrote:

> Hey folks!
>
> Apologies if I've overlooked this getting discussed already. Do we have a
> goal release cadence for minor versions out of branch-1?
>
> My first gut reaction is that it should essentially match the cadence we've
> been aiming at for the 0.98 line. That would mean attempting to match
> monthly, I think?
>
> The obvious problem with this is that now that we have patch versions, it
> means essentially getting a new branch per month for backports. That's
> quickly going to get old, even if we presume most additions will move onto
> branch-2 in a year or so.
>
> What do folks think about limiting which minor versions patch-level fixes
> go into? We could default to the most recent release + current minor dev
> and go back farther when requested by the issue filer?
>
> That means in ~3 months we'd expect branch-1 to be working on 1.4 and most
> patch-level fixes to go into branch-1.3 and branch-1. If someone reported a
> failure and they were on e.g. 1.1.z, we'd also do the fix in branch-1.1 and
> branch-1.2.
>
> Or should we just stick with hitting all of the branches on the presumption
> that the cherry picks should be trivial?
>
> --
> Sean
>