It seems like there's general consensus here (and no objections), for adopting this LTS strategy. There were some good questions raised, though, whose answers can be added to the website to communicate things. However, since the idea of releasing 1.10 came up, I'll wait for that discussion/vote/activity to settle before making any changes to the website regarding LTS.
On Mon, Nov 4, 2019 at 11:52 AM Christopher <[email protected]> wrote: > > 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. > > > > I agree with Keith about not being very prescriptive about runtime > dependencies. We can (and should) try to pay attention to dependency > lifecycles in order to inform our development in Accumulo, but > ultimately, the runtime environment is a downstream concern > (vendors/distros/packagers/users). > > What we mean by "support" may be different from other uses of that > word, especially since we're comprised of volunteers. Here, I think > what we mean is simply a declaration of our intent to focus our > development activities around those release lines in the LTS window. > It's really more of an exercise in communicating intent and managing > expectations, than it is a guarantee of anything, and certainly not > guarantees for things developed by other communities that we merely > consume.
