+1 On Mon, Nov 4, 2019 at 10:55 AM Keith Turner <[email protected]> wrote:
> 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 >
