Seems fine to me.
Any expectations on how upgrades work within an LTS release? How about
across LTS releases?
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)
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
