Final release is pretty Boss. It kind of nicely makes the policy clear w/o having to wade through a bunch of text and then do mental math to answer the question "is this EOL" and "when will this EOL".
> On Sep 12, 2022, at 10:55 AM, Regina Obe <l...@pcorp.us> wrote: > > Here is my first pass at a policy. > > https://libgeos.org/development/rfcs/rfc11/ > > If people are agreeable with it, I can put a link to it on the download page > -- https://libgeos.org/usage/download/ > > I was also thinking we should put the First Release date on this pages to > make it easier to do the math of how old a minor release is. > I think having a Final Release column might be going too far, though other > projects do that. > > > > From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of > Kurt Schwehr > Sent: Monday, September 12, 2022 12:23 PM > To: GEOS Development List <geos-devel@lists.osgeo.org> > Subject: Re: [geos-devel] End of Life Policy (EOL) > > Regina, > > Thank you! This will be a topic of discussion at the NumFocus funded > projects later this month where I will be representing GDAL. I will be > keeping an eye on the RFC and this thread for aspects that should be > discussed at the meeting. > > -kurt > > On Mon, Sep 12, 2022 at 9:19 AM Regina Obe <l...@pcorp.us> wrote: >> That works for me :) >> >> So I'll draft up an RFC to that effect. So just to be clear, that leaves >> space open to: >> >> We may put an update on such a release like 3.4 to the 3.4 branch but we >> will not bother tagging it. >> >> I'm not going to say that of course, just saying we are okay with that. >> >> Thanks, >> Regina >> >> > -----Original Message----- >> > From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of >> > Paul Ramsey >> > Sent: Monday, September 12, 2022 11:37 AM >> > To: GEOS Development List <geos-devel@lists.osgeo.org> >> > Subject: Re: [geos-devel] End of Life Policy (EOL) >> > >> > As long as the word "support" does not appear in the text. Perhaps "will >> not >> > have any further numbered releases" is more correct than "not supported". >> > >> > P >> > >> > > On Sep 12, 2022, at 8:34 AM, Regina Obe <l...@pcorp.us> wrote: >> > > >> > > I'm thinking simple fixes and serious security bugs. >> > > >> > > I think it's a given we won't break our backs to fix a particular bug >> > > if it is deemed "De-stabilizing". >> > > By De-stabilizing, I'm thinking enough code to risk causing a >> > > particular bigger issue. Pretty much the same policy we have in PostGIS >> > no? >> > > >> > > But by saying EOL we are saying we will absolutely NEVER push fixes to >> it. >> > > >> > > If some corporate paying customer is running something as crazy as >> > > 3.4, you should just fork that for them and patch it there and deal >> > > with their upgrade issues some other day. >> > > >> > > Thanks, >> > > Regina >> > > >> > > >> > > >> > > >> > >> -----Original Message----- >> > >> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On >> > >> Behalf Of Paul Ramsey >> > >> Sent: Monday, September 12, 2022 11:20 AM >> > >> To: GEOS Development List <geos-devel@lists.osgeo.org> >> > >> Subject: Re: [geos-devel] End of Life Policy (EOL) >> > >> >> > >> >> > >> >> > >>> On Sep 12, 2022, at 8:12 AM, Regina Obe <l...@pcorp.us> wrote: >> > >>> >> > >>> I'd like to make an RFC proposing a standardish End of Like Policy >> > >>> >> > >>> Does anyone have an issue with that? >> > >> >> > >> Only insofar as there's this idea that we support any particular >> > >> version >> > > at all. >> > >> Honestly, there are some bugs I just cannot be bothered to try and >> > >> fix (anything overlay pre 3.9, right? the fix there is to upgrade) >> > >> but at the >> > > same >> > >> time, I don't really mind pulling back trivial stuff pretty far. What >> > >> does >> > > it mean >> > >> to "support" this stuff anyways? Comes right down to it, if a paying >> > > customer >> > >> on 3.4 has an issue and is unable to upgrade, we'll break our fingers >> > >> to >> > > try and >> > >> fix it. But that has to do with our corporate support, not some >> > >> community commitment to support. >> > >> >> > >> ??? >> > >> >> > >> P >> > >> >> > >> >> > >>> >> > >>> I'm thinking of a policy along the lines of >> > >>> >> > >>> We support a release generally at most X plus years after the first >> > >>> version of it, but we have discretion to increase that if needed. >> > >>> >> > >>> X = 3 - 5 feels about right. >> > >>> >> > >>> How do people feel about that? >> > >>> >> > >>> If so I can draft up an RFC about that and we can edit if we are >> > >>> comfortable with that and start EOL'ing other releases besides the >> > >>> 3.5 I >> > >> recently EOL'd. >> > >>> >> > >>> Thanks, >> > >>> Regina >> > >>> >> > >>> _______________________________________________ >> > >>> geos-devel mailing list >> > >>> geos-devel@lists.osgeo.org >> > >>> https://lists.osgeo.org/mailman/listinfo/geos-devel >> > >> >> > >> _______________________________________________ >> > >> geos-devel mailing list >> > >> geos-devel@lists.osgeo.org >> > >> https://lists.osgeo.org/mailman/listinfo/geos-devel >> > > >> > > _______________________________________________ >> > > geos-devel mailing list >> > > geos-devel@lists.osgeo.org >> > > https://lists.osgeo.org/mailman/listinfo/geos-devel >> > >> > _______________________________________________ >> > geos-devel mailing list >> > geos-devel@lists.osgeo.org >> > https://lists.osgeo.org/mailman/listinfo/geos-devel >> >> _______________________________________________ >> geos-devel mailing list >> geos-devel@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/geos-devel > _______________________________________________ > geos-devel mailing list > geos-devel@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/geos-devel _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel