Since the 1.10 vote wrapped up in the other thread, it appears that we'll be releasing 1.10.0 instead of 1.9.4. Since there's general consensus in this thread about the proposed strategy, I'll start helping get the 1.10 release out with the changes we voted on, and then implementing the strategy discussed here, with 1.10 as the first LTS release (and dropping the 2.0 branch as it's not an LTS release).
Thanks for the discussion, everybody. Let's keep the conversation going, as needed, to quickly resolve any issues that arise as we proceed. On Mon, Nov 4, 2019 at 12:00 PM Christopher <[email protected]> wrote: > > 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.
