[DISCUSS] Release schedule

[Mike Miller <mm...@apache.org>]

I think it would be good for Accumulo to adopt a Long Term Support (LTS)
type release schedule.  It seems to work well for other projects like
Ubuntu and now Java is doing the same.  We could have 2 branches of LTS
versions, similar to what we have now with 1.9 and 2.0.  Then set a
schedule, say every 6 months or a year, release a minor/major version.  For
example:

1.9.0 LTS released April 2018
2.0.0 LTS released August 2019
1.10.0 LTS scheduled to release April 2020
2.x.0 LTS scheduled to release August 2021

Bug fixes for the versions can be released as needed.  We can even release
minor versions, like 2.1.0 just as a tag, and then merge into the main 2.x
branch.  That way we only ever have to deal with 2 branches.  The
motivation for this is to not have so much time (and so many changes)
between releases like we did for 2.0.  This would also help users with
scheduling upgrades.

Re: [DISCUSS] Release schedule

[Mike Miller <mm...@apache.org>]

I think we have to declare 2.0 and 1.9 LTS.  If you look back at the
history of our releases, we are basically already doing this... adding a
LTS label to a release I think would just help users.

On Mon, Aug 5, 2019 at 6:30 PM Christopher <ct...@apache.org> wrote:

> On Mon, Aug 5, 2019 at 5:49 PM Keith Turner <ke...@deenlo.com> wrote:
> >
> > On Mon, Aug 5, 2019 at 10:46 AM Mike Miller <mm...@apache.org> wrote:
> > >
> > > What happens if nobody is interested in being a release manager for a
> > > version?
> > > What happens if the schedule is missed?
> > >  - Then there is no release.  I would imagine if we can find the right
> time
> > > frame and devs are actively working, this won't be a problem though.
> > > Perhaps simplifying the release process would help ease the burden of
> > > releasing.
> >
> > Release schedule and LTS are two separate issues.  We could adopt the
> > concept of having LTS releases w/o having a fixed schedule.  I think
> > there are benefits to clearly communicating if a release will be bug
> > fixed or not.
>
> I agree with that. My hesitation is mostly about establishing concrete
> schedules, and not the LTS concept itself.
>
> I'm in favor of defining LTS. Since this is a volunteer community, we
> need to be clear that our definition of LTS is one of intent to patch
> bugs, and not a promise of support. I propose something like:
>
>  "LTS means the community intends to provide bug fix releases for that
> minor version for a 'support period' of at least 2 years, with 1 year
> of overlap between two subsequent LTS releases. Bug fix releases are
> indicated by an increment to the last element of the x.y.z version
> number. For example, if 1.6 was declared an LTS, 1.6.0 would be its
> initial release, beginning the support period, and 1.6.1, 1.6.2, etc.
> could be bug fixes releases within the support period. Non-LTS
> versions are less likely to receive bug fix releases. Instead, bugs
> for those versions are likely to be fixed in the next major/minor
> release."
>
> I'm also in favor of declaring 2.0 as LTS, to communicate our
> intentions to patch it for awhile (maybe also 1.9?).
>

Re: [DISCUSS] Release schedule

[Christopher <ct...@apache.org>]

On Mon, Aug 5, 2019 at 5:49 PM Keith Turner <ke...@deenlo.com> wrote:
>
> On Mon, Aug 5, 2019 at 10:46 AM Mike Miller <mm...@apache.org> wrote:
> >
> > What happens if nobody is interested in being a release manager for a
> > version?
> > What happens if the schedule is missed?
> >  - Then there is no release.  I would imagine if we can find the right time
> > frame and devs are actively working, this won't be a problem though.
> > Perhaps simplifying the release process would help ease the burden of
> > releasing.
>
> Release schedule and LTS are two separate issues.  We could adopt the
> concept of having LTS releases w/o having a fixed schedule.  I think
> there are benefits to clearly communicating if a release will be bug
> fixed or not.

I agree with that. My hesitation is mostly about establishing concrete
schedules, and not the LTS concept itself.

I'm in favor of defining LTS. Since this is a volunteer community, we
need to be clear that our definition of LTS is one of intent to patch
bugs, and not a promise of support. I propose something like:

 "LTS means the community intends to provide bug fix releases for that
minor version for a 'support period' of at least 2 years, with 1 year
of overlap between two subsequent LTS releases. Bug fix releases are
indicated by an increment to the last element of the x.y.z version
number. For example, if 1.6 was declared an LTS, 1.6.0 would be its
initial release, beginning the support period, and 1.6.1, 1.6.2, etc.
could be bug fixes releases within the support period. Non-LTS
versions are less likely to receive bug fix releases. Instead, bugs
for those versions are likely to be fixed in the next major/minor
release."

I'm also in favor of declaring 2.0 as LTS, to communicate our
intentions to patch it for awhile (maybe also 1.9?).

Re: [DISCUSS] Release schedule

[Keith Turner <ke...@deenlo.com>]

On Mon, Aug 5, 2019 at 10:46 AM Mike Miller <mm...@apache.org> wrote:
>
> What happens if nobody is interested in being a release manager for a
> version?
> What happens if the schedule is missed?
>  - Then there is no release.  I would imagine if we can find the right time
> frame and devs are actively working, this won't be a problem though.
> Perhaps simplifying the release process would help ease the burden of
> releasing.

Release schedule and LTS are two separate issues.  We could adopt the
concept of having LTS releases w/o having a fixed schedule.  I think
there are benefits to clearly communicating if a release will be bug
fixed or not.

>
> Who handles reminders for scheduling new releases?
> - We can post the schedule.  Reminders are optional, if someone wants to
> notify the community they can.
>
> Will we establish freeze deadlines for features?
> How do we enforce freezes in the C-T-R model?
> - I think that is a good idea.  We could do an API freeze further out, say
> like 3 months.  Then a full freeze a week before.  A tag could be created
> to freeze the code.
>
> What if there's nothing compelling a release when a scheduled release
> is approaching?
> What happens if a scheduled release is approaching, but the community
> is focused on critical patches for a previous release?
> - Same as my first comment.  I also think "compelling" is difficult to
> define, so we shouldn't worry about that.  A single bug fix could be
> compelling to someone.  I think its different for everyone.   Even a LTS
> release that is 100% bug fixes with no new features  could be compelling to
> a team who is resistant to upgrading.
>
> On Fri, Aug 2, 2019 at 2:35 PM Christopher <ct...@apache.org> wrote:
>
> > I'm in favor of this generally, but worry a bit about making release
> > schedule guarantees, due to the volunteer nature of the project Apache
> > projects in general.
> >
> > What happens if nobody is interested in being a release manager for a
> > version?
> > What happens if the schedule is missed?
> > Who handles reminders for scheduling new releases?
> > Will we establish freeze deadlines for features?
> > How do we enforce freezes in the C-T-R model?
> > What if there's nothing compelling a release when a scheduled release
> > is approaching?
> > What happens if a scheduled release is approaching, but the community
> > is focused on critical patches for a previous release?
> >
> > On Fri, Aug 2, 2019 at 12:43 PM Keith Turner <ke...@deenlo.com> wrote:
> > >
> > > I am in favor of this. One possible way to move this forward would be
> > > to write the following two proposals.
> > >
> > >   * Transition proposal :  lays out how we will transition to this
> > > plan.  For example it could outline that 1.9 will become the first
> > > LTS.
> > >   *  Release schedule proposal : lays out how the Accumulo release
> > > schedule would work.
> > >
> > > The proposals could be made as website PRs and discussion could happen
> > > on the PR. If the proposals are adopted by the community, then they
> > > could be turned into documentation.
> > >
> > > On Fri, Aug 2, 2019 at 12:08 PM Mike Miller <mm...@apache.org> wrote:
> > > >
> > > > I think it would be good for Accumulo to adopt a Long Term Support
> > (LTS)
> > > > type release schedule.  It seems to work well for other projects like
> > > > Ubuntu and now Java is doing the same.  We could have 2 branches of LTS
> > > > versions, similar to what we have now with 1.9 and 2.0.  Then set a
> > > > schedule, say every 6 months or a year, release a minor/major
> > version.  For
> > > > example:
> > > >
> > > > 1.9.0 LTS released April 2018
> > > > 2.0.0 LTS released August 2019
> > > > 1.10.0 LTS scheduled to release April 2020
> > > > 2.x.0 LTS scheduled to release August 2021
> > > >
> > > > Bug fixes for the versions can be released as needed.  We can even
> > release
> > > > minor versions, like 2.1.0 just as a tag, and then merge into the main
> > 2.x
> > > > branch.  That way we only ever have to deal with 2 branches.  The
> > > > motivation for this is to not have so much time (and so many changes)
> > > > between releases like we did for 2.0.  This would also help users with
> > > > scheduling upgrades.
> >

Re: [DISCUSS] Release schedule

[Mike Miller <mm...@apache.org>]

What happens if nobody is interested in being a release manager for a
version?
What happens if the schedule is missed?
 - Then there is no release.  I would imagine if we can find the right time
frame and devs are actively working, this won't be a problem though.
Perhaps simplifying the release process would help ease the burden of
releasing.

Who handles reminders for scheduling new releases?
- We can post the schedule.  Reminders are optional, if someone wants to
notify the community they can.

Will we establish freeze deadlines for features?
How do we enforce freezes in the C-T-R model?
- I think that is a good idea.  We could do an API freeze further out, say
like 3 months.  Then a full freeze a week before.  A tag could be created
to freeze the code.

What if there's nothing compelling a release when a scheduled release
is approaching?
What happens if a scheduled release is approaching, but the community
is focused on critical patches for a previous release?
- Same as my first comment.  I also think "compelling" is difficult to
define, so we shouldn't worry about that.  A single bug fix could be
compelling to someone.  I think its different for everyone.   Even a LTS
release that is 100% bug fixes with no new features  could be compelling to
a team who is resistant to upgrading.

On Fri, Aug 2, 2019 at 2:35 PM Christopher <ct...@apache.org> wrote:

> I'm in favor of this generally, but worry a bit about making release
> schedule guarantees, due to the volunteer nature of the project Apache
> projects in general.
>
> What happens if nobody is interested in being a release manager for a
> version?
> What happens if the schedule is missed?
> Who handles reminders for scheduling new releases?
> Will we establish freeze deadlines for features?
> How do we enforce freezes in the C-T-R model?
> What if there's nothing compelling a release when a scheduled release
> is approaching?
> What happens if a scheduled release is approaching, but the community
> is focused on critical patches for a previous release?
>
> On Fri, Aug 2, 2019 at 12:43 PM Keith Turner <ke...@deenlo.com> wrote:
> >
> > I am in favor of this. One possible way to move this forward would be
> > to write the following two proposals.
> >
> >   * Transition proposal :  lays out how we will transition to this
> > plan.  For example it could outline that 1.9 will become the first
> > LTS.
> >   *  Release schedule proposal : lays out how the Accumulo release
> > schedule would work.
> >
> > The proposals could be made as website PRs and discussion could happen
> > on the PR. If the proposals are adopted by the community, then they
> > could be turned into documentation.
> >
> > On Fri, Aug 2, 2019 at 12:08 PM Mike Miller <mm...@apache.org> wrote:
> > >
> > > I think it would be good for Accumulo to adopt a Long Term Support
> (LTS)
> > > type release schedule.  It seems to work well for other projects like
> > > Ubuntu and now Java is doing the same.  We could have 2 branches of LTS
> > > versions, similar to what we have now with 1.9 and 2.0.  Then set a
> > > schedule, say every 6 months or a year, release a minor/major
> version.  For
> > > example:
> > >
> > > 1.9.0 LTS released April 2018
> > > 2.0.0 LTS released August 2019
> > > 1.10.0 LTS scheduled to release April 2020
> > > 2.x.0 LTS scheduled to release August 2021
> > >
> > > Bug fixes for the versions can be released as needed.  We can even
> release
> > > minor versions, like 2.1.0 just as a tag, and then merge into the main
> 2.x
> > > branch.  That way we only ever have to deal with 2 branches.  The
> > > motivation for this is to not have so much time (and so many changes)
> > > between releases like we did for 2.0.  This would also help users with
> > > scheduling upgrades.
>

Re: [DISCUSS] Release schedule

[Christopher <ct...@apache.org>]

I'm in favor of this generally, but worry a bit about making release
schedule guarantees, due to the volunteer nature of the project Apache
projects in general.

What happens if nobody is interested in being a release manager for a version?
What happens if the schedule is missed?
Who handles reminders for scheduling new releases?
Will we establish freeze deadlines for features?
How do we enforce freezes in the C-T-R model?
What if there's nothing compelling a release when a scheduled release
is approaching?
What happens if a scheduled release is approaching, but the community
is focused on critical patches for a previous release?

On Fri, Aug 2, 2019 at 12:43 PM Keith Turner <ke...@deenlo.com> wrote:
>
> I am in favor of this. One possible way to move this forward would be
> to write the following two proposals.
>
>   * Transition proposal :  lays out how we will transition to this
> plan.  For example it could outline that 1.9 will become the first
> LTS.
>   *  Release schedule proposal : lays out how the Accumulo release
> schedule would work.
>
> The proposals could be made as website PRs and discussion could happen
> on the PR. If the proposals are adopted by the community, then they
> could be turned into documentation.
>
> On Fri, Aug 2, 2019 at 12:08 PM Mike Miller <mm...@apache.org> wrote:
> >
> > I think it would be good for Accumulo to adopt a Long Term Support (LTS)
> > type release schedule.  It seems to work well for other projects like
> > Ubuntu and now Java is doing the same.  We could have 2 branches of LTS
> > versions, similar to what we have now with 1.9 and 2.0.  Then set a
> > schedule, say every 6 months or a year, release a minor/major version.  For
> > example:
> >
> > 1.9.0 LTS released April 2018
> > 2.0.0 LTS released August 2019
> > 1.10.0 LTS scheduled to release April 2020
> > 2.x.0 LTS scheduled to release August 2021
> >
> > Bug fixes for the versions can be released as needed.  We can even release
> > minor versions, like 2.1.0 just as a tag, and then merge into the main 2.x
> > branch.  That way we only ever have to deal with 2 branches.  The
> > motivation for this is to not have so much time (and so many changes)
> > between releases like we did for 2.0.  This would also help users with
> > scheduling upgrades.

Re: [DISCUSS] Release schedule

[Keith Turner <ke...@deenlo.com>]

I am in favor of this. One possible way to move this forward would be
to write the following two proposals.

  * Transition proposal :  lays out how we will transition to this
plan.  For example it could outline that 1.9 will become the first
LTS.
  *  Release schedule proposal : lays out how the Accumulo release
schedule would work.

The proposals could be made as website PRs and discussion could happen
on the PR. If the proposals are adopted by the community, then they
could be turned into documentation.

On Fri, Aug 2, 2019 at 12:08 PM Mike Miller <mm...@apache.org> wrote:
>
> I think it would be good for Accumulo to adopt a Long Term Support (LTS)
> type release schedule.  It seems to work well for other projects like
> Ubuntu and now Java is doing the same.  We could have 2 branches of LTS
> versions, similar to what we have now with 1.9 and 2.0.  Then set a
> schedule, say every 6 months or a year, release a minor/major version.  For
> example:
>
> 1.9.0 LTS released April 2018
> 2.0.0 LTS released August 2019
> 1.10.0 LTS scheduled to release April 2020
> 2.x.0 LTS scheduled to release August 2021
>
> Bug fixes for the versions can be released as needed.  We can even release
> minor versions, like 2.1.0 just as a tag, and then merge into the main 2.x
> branch.  That way we only ever have to deal with 2 branches.  The
> motivation for this is to not have so much time (and so many changes)
> between releases like we did for 2.0.  This would also help users with
> scheduling upgrades.