What sort of major release support plan do we want to provide?

[Joe Witt <jo...@gmail.com>]

Team,

We should discuss an important topic that Sean Busbey raised which is
what is our plan to support major release lines.

We should identify:
- how long to support the previous major release line(s)
- what type of support we'd provide (feature porting, bugs only,
critical bugs only, critical security bugs only)

I would like to propose that we only offer critical security bug fixes
to old release lines as a general philosophy.  But I am certainly ears
open to understanding a broader view from users or those more
experienced managing these sorts of projects.

Look forward to seeing some thoughtful perspectives and inputs.

Thanks
Joe

Re: What sort of major release support plan do we want to provide?

[Joey Echeverria <jo...@gmail.com>]

Assuming major upgrades will sometimes break compatibility, I think we need
to plan on providing general bug fixes, not just security or critical
fixes, to at least the last major release. I like the idea of those patch
releases becoming less frequent as the age of the release increases. I
don't think we should prioritize new features for older major releases, but
I could imagine there will be times when it's required like in situations
like HBase 0.94 that Sean mentioned.

For releases older than N-1, I'd think only critical bugs and security
fixes are needed. Assuming we get a good cadence of major releases, I think
that dropping support for anything older than N-2 or N-3 would also make
sense.

-Joey

On Tue, Sep 29, 2015 at 11:19 AM, Sean Busbey <bu...@cloudera.com> wrote:

> As the project matures, I expect at least part of major release line
> lifetime will be driven by adoption since we're volunteer driven.
>
> For example, HBase 0.94 (a major release line) has outlived HBase 0.96
> and may outlive 0.98 yet (both major release lines). Part of this was
> because the community failed to provide a zero-downtime option for
> upgrading off of 0.94, but some of it is just a matter of timing and
> upgrade cycles in large IT shops. Development on the line has
> progressively slowed; it got new features for some time, but has been
> locked into critical bug fixes for about a year now.
>
> Part of the reason HBase has been able to use an adaptive lifetime for
> release lines is that we get a volunteer to sign up as Release Manager
> (originally over a major release's life and lately over a minor). That
> RM then did the majority of work monitoring the activity of a branch
> line. As incoming patches slow down they take the lead in 1) ensuring
> that critical patches devs forget to backport still show up before
> release, and 2) driving community expectations around the branch (e.g.
> "I'm planning to slow the release cycle to quarterly, so anyone think
> that'll adversely impact them too much?"). Full disclosure, HBase
> hasn't worked out changes to major release lifecycle since it
> transitioned to have patch releases (post 1.0.0) back in February; for
> now we just wait for activity to slow on minor releases like we did
> for the older major releases.
>
>
>
> On Tue, Sep 29, 2015 at 9:31 AM, Joe Witt <jo...@gmail.com> wrote:
> > Team,
> >
> > We should discuss an important topic that Sean Busbey raised which is
> > what is our plan to support major release lines.
> >
> > We should identify:
> > - how long to support the previous major release line(s)
> > - what type of support we'd provide (feature porting, bugs only,
> > critical bugs only, critical security bugs only)
> >
> > I would like to propose that we only offer critical security bug fixes
> > to old release lines as a general philosophy.  But I am certainly ears
> > open to understanding a broader view from users or those more
> > experienced managing these sorts of projects.
> >
> > Look forward to seeing some thoughtful perspectives and inputs.
> >
> > Thanks
> > Joe
>
>
>
> --
> Sean
>

Re: What sort of major release support plan do we want to provide?

[Sean Busbey <bu...@cloudera.com>]

As the project matures, I expect at least part of major release line
lifetime will be driven by adoption since we're volunteer driven.

For example, HBase 0.94 (a major release line) has outlived HBase 0.96
and may outlive 0.98 yet (both major release lines). Part of this was
because the community failed to provide a zero-downtime option for
upgrading off of 0.94, but some of it is just a matter of timing and
upgrade cycles in large IT shops. Development on the line has
progressively slowed; it got new features for some time, but has been
locked into critical bug fixes for about a year now.

Part of the reason HBase has been able to use an adaptive lifetime for
release lines is that we get a volunteer to sign up as Release Manager
(originally over a major release's life and lately over a minor). That
RM then did the majority of work monitoring the activity of a branch
line. As incoming patches slow down they take the lead in 1) ensuring
that critical patches devs forget to backport still show up before
release, and 2) driving community expectations around the branch (e.g.
"I'm planning to slow the release cycle to quarterly, so anyone think
that'll adversely impact them too much?"). Full disclosure, HBase
hasn't worked out changes to major release lifecycle since it
transitioned to have patch releases (post 1.0.0) back in February; for
now we just wait for activity to slow on minor releases like we did
for the older major releases.



On Tue, Sep 29, 2015 at 9:31 AM, Joe Witt <jo...@gmail.com> wrote:
> Team,
>
> We should discuss an important topic that Sean Busbey raised which is
> what is our plan to support major release lines.
>
> We should identify:
> - how long to support the previous major release line(s)
> - what type of support we'd provide (feature porting, bugs only,
> critical bugs only, critical security bugs only)
>
> I would like to propose that we only offer critical security bug fixes
> to old release lines as a general philosophy.  But I am certainly ears
> open to understanding a broader view from users or those more
> experienced managing these sorts of projects.
>
> Look forward to seeing some thoughtful perspectives and inputs.
>
> Thanks
> Joe



-- 
Sean