> On Feb 15, 2017, at 9:14 AM, Sterling Hughes > <[email protected]> wrote: > > Hi, > >>> 1. We might want to explicitly define the meaning of "releases that are >>> still supported" (mentioned under Release Schedule); for instance, is it >>> only the current major release, or one or two prior releases as well? The >>> section on Backwards Compatibility talks about active and deprecated >>> features at a more granular level, but not the definition of supported >>> releases. >>> >> >> This may be different with each major release. For example, 1.1 may be >> supported but 1.2 might not (say there’s a horrible bug). I will add >> language about supported releases and when a release may not be supported. >> > > I don’t think this should be arbitrary. We need to have a consistent policy > here, that addresses bug fixes and security fixes. If there is a horrible > bug, and it’s a supported release, we should issue a patch.
Yes, for supported releases. But how do we decide which is a long-term supported (LTS) release? Is that part of the voting process for a release candidate? > > I think, at least for the next few releases, we want people to be following > the release train pretty closely — so we shouldn’t maintain support for prior > releases, except for security fixes, which should go 2 releases back. Once > we hit our first LTS release, we should review this policy. OK. We can call it "limited support” - critical and security fixes only. I agree that we want users/developers to be moving along with the rapid developments for now. > > Thoughts? > > Sterling thanks, aditi
