On Fri, Nov 1, 2019 at 7:43 PM Nikhil Manchanda <[email protected]> wrote: > > > +1 > (non-binding) > > I'm in favor of the LTS proposal as it stands. It provides a clear > way for our development and release teams to signal to users the > expected life of an Accumulo release. It also puts in place a > basic framework in terms of what we consider reasonable windows > for patching and support. It also gives developers an avenue to > run some of the more creative experiments on non LTS lines without > affecting stability of LTS releases. > > Totally agree that this is likely going to be an evolving effort > as we find what works well here. That said, this is a great > starting point. > > One question that I did have (especially being new in the area) is > whether we have any dependencies that themselves offer support for > shorter periods of time than our (3-year) LTS window. If so, does > that mean that we might be on the hook for any issues discovered > with such dependencies?
I have always viewed Accumulo as not being very prescriptive about what dependencies are used at runtime. For the situation you mention, if Accumulo source needs to change in order to allow a newer version of a dep to be used for security reasons we could make that change in a patch version. Ideally the Accumulo source change allows the new and old version of the dependency to be used. If this is not possible, personally I would still like to see the change made with a prominent mention in the release notes. > > Thanks, > Nikhil > > > On Thu, Oct 31 2019, Keith Turner <[email protected]> wrote: > > +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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724%40%253Cdev.accumulo.apache.org%253E&data=02%7C01%7C%7Cccae8357ee444dac038f08d75e029b6e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637081237595720486&sdata=OFd9ssV3kP4jwOxcjOKkMPUil%2B%2B0bzhPbfbmPCU1i7Q%3D&reserved=0 > >> > >> 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
