On Feb 15, 2017, at 9:48 AM, Peter Saint-Andre - Filament <[email protected]> wrote:
> On 2/15/17 10:41 AM, aditi hilbert wrote: >> >>> 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? > > Right, that was my question. Having this be policy enables folks to plan. > > Peter > At minimum, the policy could be that one previous major release is LTS. If its a minor or patch release, those patches will get back into Master so they don’t have to be supported Long Term. So, when we release 1.0 (which is a major release) we will support it till 1.2 (assuming 1.1 is a major release). When we release 1.1, the release notes will state that 1.0 release is LTS and will not be supported after the next major release. > -- > Peter Saint-Andre > https://filament.com/
