On Thu, Oct 31, 2019 at 10:28 AM Josh Elser <[email protected]> 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. > > 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) > * Can any LTS release (1.9.1) be guaranteed to upgrade to a later LTS > release (2.3.1)? > * What about rolling back in an LTS release (e.g. 2.3.2 back to 2.3.1 > after some bug is found) 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). > > 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 > >
