On Mon, Aug 5, 2019 at 5:49 PM Keith Turner <[email protected]> wrote: > > On Mon, Aug 5, 2019 at 10:46 AM Mike Miller <[email protected]> wrote: > > > > What happens if nobody is interested in being a release manager for a > > version? > > What happens if the schedule is missed? > > - Then there is no release. I would imagine if we can find the right time > > frame and devs are actively working, this won't be a problem though. > > Perhaps simplifying the release process would help ease the burden of > > releasing. > > Release schedule and LTS are two separate issues. We could adopt the > concept of having LTS releases w/o having a fixed schedule. I think > there are benefits to clearly communicating if a release will be bug > fixed or not.
I agree with that. My hesitation is mostly about establishing concrete schedules, and not the LTS concept itself. I'm in favor of defining LTS. Since this is a volunteer community, we need to be clear that our definition of LTS is one of intent to patch bugs, and not a promise of support. I propose something like: "LTS means the community intends to provide bug fix releases for that minor version for a 'support period' of at least 2 years, with 1 year of overlap between two subsequent LTS releases. Bug fix releases are indicated by an increment to the last element of the x.y.z version number. For example, if 1.6 was declared an LTS, 1.6.0 would be its initial release, beginning the support period, and 1.6.1, 1.6.2, etc. could be bug fixes releases within the support period. Non-LTS versions are less likely to receive bug fix releases. Instead, bugs for those versions are likely to be fixed in the next major/minor release." I'm also in favor of declaring 2.0 as LTS, to communicate our intentions to patch it for awhile (maybe also 1.9?).
