+1 I am in favor of the LTS idea because I think it makes it more efficient for everyone to easily come together and focus their efforts in the same direction for the benefit of everyone.
I think this is a really good starting plan for LTS. Overtime we will probably find issues with the plan and we can modify the plan as we go. I can help write up the documentation for the initial plan. One thing I would like to achieve in the writeup is communicating that things are not set in stone. Thinking through this I thought about possibly including the following points in the writeup. * Any plans for the next LTS are subject to change. * Patches for the current LTS will be accepted until at least the currently agreed date. * Changes to the LTS process can be brought up on the dev list. On Wed, Oct 30, 2019 at 9:00 PM Christopher <[email protected]> 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
