Re: [LAZY][VOTE] A basic, but concrete, LTS proposal

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

On Thu, Oct 31, 2019 at 10:46 AM Keith Turner <ke...@deenlo.com> wrote:
>
> On Thu, Oct 31, 2019 at 10:28 AM Josh Elser <el...@apache.org> wrote:
> >
> > Seems fine to me.
> >
> > Any expectations on how upgrades work within an LTS release? How about
> > across LTS releases?
>
> The behavior I would like to see is that for any release you can
> always upgrade from the previous release.  For LTS releases you can
> upgrade from two releases, the last non-LTS and last LTS release.
>

That'd be my expectation as well.

> >
> > Some specific situations to mull over:
> >
> > * Can rolling upgrade in an LTS release (to new patch version) with no
> > downtime. (e.g. 1.9.1 to 1.9.3)

Because patch releases for an LTS would be patch releases, and not
major/minor bumps, I'd expect it to follow our current practice of not
bumping the DATA version or the WIRE version within these. We don't
guarantee rolling upgrade support today, and this doesn't change
that... but it's as close as we can get I think.

> > * Can any LTS release (1.9.1) be guaranteed to upgrade to a later LTS
> > release (2.3.1)?

Because of the work involved in testing, I would expect LTS releases
to be upgradable from (confirmed via testing) the latest patch release
in the previous LTS line, but I wouldn't expect us to test every
previous patch release in that LTS line. Because of the way we
minimize/limit changes to bugfixes in patch releases already, I'd
expect these combinations to work, but wouldn't expect us to test each
combination. Also, patch releases can fix bugs in the upgrade process,
itself, so I don't think it'd be unreasonable to expect people to be
already running the latest patch before upgrading to the next LTS.

> > * What about rolling back in an LTS release (e.g. 2.3.2 back to 2.3.1
> > after some bug is found)

We already expect that to work today, so LTS wouldn't change that. The
main point of LTS is to manage our development priorities by creating
more well-defined lifecycles for major/minor versions and
communicating those priorities to users. It doesn't actually change
what a major/minor/patch release means, though.

>
> Being able to roll back an upgrade was one motivation for the following.
>
> https://accumulo.apache.org/design/system-snapshot.html
>
> >
> > Not looking for immediate answers, but it would be good to define the
> > expectations you have around what we want Accumulo to be able to do
> > (ignoring the fact that bugs will certainly arise around
> > upgrades/downgrades).
> >

We can collect these into a FAQs section of a page describing our
versioning (semver) and LTS release strategies in one place, and keep
them updated as new points are raised.

> > On 10/30/19 9:00 PM, Christopher wrote:
> > > Following up from the discussion at
> > > https://lists.apache.org/thread.html/560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724@%3Cdev.accumulo.apache.org%3E
> > >
> > > I think we should adopt this LTS concept:
> > >
> > > LTS releases:
> > > * Designate a new LTS line every 2 years (designation communicates
> > > intent to support/patch)
> > > * Target patch releases to LTS lines for 3 years
> > > * EOL previous LTS line when the new one has been available for 1 year
> > >
> > > non-LTS releases:
> > > * Periodic releases that aren't expected to be supported with patch releases
> > > * Can still create patch releases, but only until the next LTS/non-LTS
> > > release line (typically only for critical bugs.... because we won't
> > > keep a maintenance branch around for non-LTS... instead, we'll roll
> > > bugfixes into the next release, or branch off the tag for a critical
> > > bug)
> > > * non-LTS releases are EOL as soon as the next LTS/non-LTS release
> > > line is created
> > >
> > > Transition plan:
> > >
> > > * Define LTS on the downloads page of the website
> > > * Designate 1.9 as first (and currently only) LTS release line
> > > * Mark the LTS expected EOL date on the downloads page next to the LTS
> > > releases (to the month... we don't need to get too granular/pedantic)
> > >
> > > What this proposal does *not* do is determine how frequently we
> > > release. It *only* determines which versions we will designate as LTS.
> > > So, this doesn't bind us to any fixed release schedule, and we can
> > > release as frequently (or infrequently) as our community wishes
> > > (though I hope the non-LTS releases will occur more frequently, as
> > > they can take more creative risks). But, the main point of this
> > > proposal is that every two years, we'll designate a new release that
> > > will take over as our main "supported line" that will be low-risk, and
> > > more stable over time. The 1-year overlap for people to upgrade from
> > > one LTS to the next in this plan is pretty useful, too, I think.
> > >
> > > Here's an example set of hypothetical releases (except 1.9.x and
> > > 2.0.0, which are real) under this plan:
> > >
> > > * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
> > > * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug fix) -> 2.2.0
> > > * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
> > > * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
> > > * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
> > >
> > > This LTS proposal isn't perfect and doesn't solve all possible issues,
> > > but I think it establishes the groundwork for future release
> > > plans/schedules and helps frame discussions about future releases,
> > > that we can work through later if needed.
> > >
> > > If there's general consensus on the basic proposal here, I can start
> > > updating the website after 72 hours (lazy consensus) to add the LTS
> > > definition and mark things on the downloads page, accordingly. If it
> > > turns into a significant discussion, I'll hold off on anything until
> > > the discussion points are resolved. If there's disagreement that can't
> > > be resolved, I'll start a more formal vote later (or give up due to
> > > lost motivation, worst case :smile:).
> > >
> > > --
> > > Christopher
> > >

RE: [LAZY][VOTE] A basic, but concrete, LTS proposal

["Owens, Mark" <jm...@evoforge.org>]

+1

-----Original Message-----
From: Christopher <ct...@apache.org> 
Sent: Thursday, October 31, 2019 8:35 PM
To: accumulo-dev <de...@accumulo.apache.org>
Subject: Re: [LAZY][VOTE] A basic, but concrete, LTS proposal

On Thu, Oct 31, 2019 at 10:46 AM Keith Turner <ke...@deenlo.com> wrote:
>
> On Thu, Oct 31, 2019 at 10:28 AM Josh Elser <el...@apache.org> wrote:
> >
> > Seems fine to me.
> >
> > Any expectations on how upgrades work within an LTS release? How 
> > about across LTS releases?
>
> The behavior I would like to see is that for any release you can 
> always upgrade from the previous release.  For LTS releases you can 
> upgrade from two releases, the last non-LTS and last LTS release.
>

That'd be my expectation as well.

> >
> > Some specific situations to mull over:
> >
> > * Can rolling upgrade in an LTS release (to new patch version) with 
> > no downtime. (e.g. 1.9.1 to 1.9.3)

Because patch releases for an LTS would be patch releases, and not major/minor bumps, I'd expect it to follow our current practice of not bumping the DATA version or the WIRE version within these. We don't guarantee rolling upgrade support today, and this doesn't change that... but it's as close as we can get I think.

> > * Can any LTS release (1.9.1) be guaranteed to upgrade to a later 
> > LTS release (2.3.1)?

Because of the work involved in testing, I would expect LTS releases to be upgradable from (confirmed via testing) the latest patch release in the previous LTS line, but I wouldn't expect us to test every previous patch release in that LTS line. Because of the way we minimize/limit changes to bugfixes in patch releases already, I'd expect these combinations to work, but wouldn't expect us to test each combination. Also, patch releases can fix bugs in the upgrade process, itself, so I don't think it'd be unreasonable to expect people to be already running the latest patch before upgrading to the next LTS.

> > * What about rolling back in an LTS release (e.g. 2.3.2 back to 
> > 2.3.1 after some bug is found)

We already expect that to work today, so LTS wouldn't change that. The main point of LTS is to manage our development priorities by creating more well-defined lifecycles for major/minor versions and communicating those priorities to users. It doesn't actually change what a major/minor/patch release means, though.

>
> Being able to roll back an upgrade was one motivation for the following.
>
> https://accumulo.apache.org/design/system-snapshot.html
>
> >
> > Not looking for immediate answers, but it would be good to define 
> > the expectations you have around what we want Accumulo to be able to 
> > do (ignoring the fact that bugs will certainly arise around 
> > upgrades/downgrades).
> >

We can collect these into a FAQs section of a page describing our versioning (semver) and LTS release strategies in one place, and keep them updated as new points are raised.

> > On 10/30/19 9:00 PM, Christopher wrote:
> > > Following up from the discussion at 
> > > https://lists.apache.org/thread.html/560bfe8d911be5b829e6250a34dfa
> > > 1ace0584b24251651be1c77d724@%3Cdev.accumulo.apache.org%3E
> > >
> > > I think we should adopt this LTS concept:
> > >
> > > LTS releases:
> > > * Designate a new LTS line every 2 years (designation communicates 
> > > intent to support/patch)
> > > * Target patch releases to LTS lines for 3 years
> > > * EOL previous LTS line when the new one has been available for 1 
> > > year
> > >
> > > non-LTS releases:
> > > * Periodic releases that aren't expected to be supported with 
> > > patch releases
> > > * Can still create patch releases, but only until the next 
> > > LTS/non-LTS release line (typically only for critical bugs.... 
> > > because we won't keep a maintenance branch around for non-LTS... 
> > > instead, we'll roll bugfixes into the next release, or branch off 
> > > the tag for a critical
> > > bug)
> > > * non-LTS releases are EOL as soon as the next LTS/non-LTS release 
> > > line is created
> > >
> > > Transition plan:
> > >
> > > * Define LTS on the downloads page of the website
> > > * Designate 1.9 as first (and currently only) LTS release line
> > > * Mark the LTS expected EOL date on the downloads page next to the 
> > > LTS releases (to the month... we don't need to get too 
> > > granular/pedantic)
> > >
> > > What this proposal does *not* do is determine how frequently we 
> > > release. It *only* determines which versions we will designate as LTS.
> > > So, this doesn't bind us to any fixed release schedule, and we can 
> > > release as frequently (or infrequently) as our community wishes 
> > > (though I hope the non-LTS releases will occur more frequently, as 
> > > they can take more creative risks). But, the main point of this 
> > > proposal is that every two years, we'll designate a new release 
> > > that will take over as our main "supported line" that will be 
> > > low-risk, and more stable over time. The 1-year overlap for people 
> > > to upgrade from one LTS to the next in this plan is pretty useful, too, I think.
> > >
> > > Here's an example set of hypothetical releases (except 1.9.x and 
> > > 2.0.0, which are real) under this plan:
> > >
> > > * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
> > > * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug fix) 
> > > -> 2.2.0
> > > * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
> > > * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
> > > * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
> > >
> > > This LTS proposal isn't perfect and doesn't solve all possible 
> > > issues, but I think it establishes the groundwork for future 
> > > release plans/schedules and helps frame discussions about future 
> > > releases, that we can work through later if needed.
> > >
> > > If there's general consensus on the basic proposal here, I can 
> > > start updating the website after 72 hours (lazy consensus) to add 
> > > the LTS definition and mark things on the downloads page, 
> > > accordingly. If it turns into a significant discussion, I'll hold 
> > > off on anything until the discussion points are resolved. If 
> > > there's disagreement that can't be resolved, I'll start a more 
> > > formal vote later (or give up due to lost motivation, worst case :smile:).
> > >
> > > --
> > > Christopher
> > >