I'm fine with that as well On Fri, Aug 2, 2019, 15:55 Rawlin Peters <[email protected]> wrote:
> +1 > > At our current release cadence, that sounds good to me. > > - Rawlin > > On Fri, Aug 2, 2019 at 10:46 AM Dave Neuman <[email protected]> wrote: > > > > I think we want to support the latest two Minor or Major versions, not > just > > the latest two Major versions. When 3.1 is released we support 3.0.1 and > > 3.1 and no longer support 2.2. The reason is that our releases > (especially > > Major ones) are very infrequent and it’s not practical to support a > release > > that’s 12-18 months old. I believe it’s a reasonable expectation that > our > > users will stay relatively current especially given the size and > frequency > > of our releases. > > > > On Fri, Aug 2, 2019 at 07:15 ocket 8888 <[email protected]> wrote: > > > > > I agree, when the latest release is version X.Y.Z and Y=0 then version > > > X-1.a.b should receive both bug and security fixes (where a is the > latest > > > minor version of release X-1 and b is the latest patch of that > version). > > > But when Y>0, X-1.a.b receives only security updates and X.Y-1.b gets > both > > > bugfixes and security updates. > > > but maybe that's too big a commitment. > > > > > > On Thu, Aug 1, 2019 at 2:41 PM Rawlin Peters <[email protected]> > > > wrote: > > > > > > > There is a 3.0.1 tag, but yeah I was looking for it in the releases > page > > > > too. > > > > > > > > There is also the question of supporting security fixes vs important > > > > bug fixes. A lot of projects will support just security fixes for the > > > > "older" versions and both security and bug fixes for the "newer" > > > > versions. Would we want to support security fixes for 2.2.0 (latest > > > > version of the previous major) and bug+security fixes for 3.0.1 > > > > (latest version of the current major)? > > > > > > > > - Rawlin > > > > > > > > On Thu, Aug 1, 2019 at 1:38 PM Jeremy Mitchell < > [email protected]> > > > > wrote: > > > > > > > > > > the latest 2 sounds good to me. i.e. > > > > > > > > > > - 2.2.0 > > > > > - 3.0.1 (soon to be 3.1.0) > > > > > > > > > > also, shouldn't this say 3.0.1? > > > > > https://github.com/apache/trafficcontrol/releases > > > > > > > > > > On Thu, Aug 1, 2019 at 11:57 AM Rawlin Peters < > [email protected] > > > > > > > > > wrote: > > > > > > > > > > > I'm not sure if this is what the community has "officially" > agreed to > > > > > > or not, but I think we support the latest versions of the last > two > > > > > > major releases. E.g. I think at this point in time we support > 2.2 and > > > > > > 3.0.1 (the latest versions of the last two major releases). When > we > > > > > > release 3.1, does that mean we no longer support 3.0.1 but still > > > > > > support 2.2? > > > > > > > > > > > > - Rawlin > > > > > > > > > > > > On Thu, Aug 1, 2019 at 11:46 AM ocket 8888 <[email protected]> > > > > wrote: > > > > > > > > > > > > > > So I wanted to add a GitHub security policy, since presumably > > > people > > > > will > > > > > > > start checking those for information regarding sec vuln > disclosures > > > > (the > > > > > > PR > > > > > > > is here: https://github.com/apache/trafficcontrol/pull/3757). > One > > > > of the > > > > > > > things they wanted to know, though, was what releases are > receiving > > > > > > > security updates. Which is something that isn't described > anywhere > > > > afaik. > > > > > > > So what I put in there for now was 2.2.x and 3.0.x But with > 3.1.0 > > > > coming > > > > > > > soon, will we be dropping support for one or both of those? > What's > > > > the > > > > > > > 'official' policy on that? > > > > > > > > > > > > > >
