[geos-devel] End of Life Policy (EOL)

[Paul Ramsey]

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 <lr at 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-bounces at lists.osgeo.org] On Behalf Of Kurt Schwehr
> Sent: Monday, September 12, 2022 12:23 PM
> To: GEOS Development List <geos-devel at 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 <lr at 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-bounces at lists.osgeo.org] On Behalf Of
>> > Paul Ramsey
>> > Sent: Monday, September 12, 2022 11:37 AM
>> > To: GEOS Development List <geos-devel at 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 <lr at 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-bounces at lists.osgeo.org] On
>> > >> Behalf Of Paul Ramsey
>> > >> Sent: Monday, September 12, 2022 11:20 AM
>> > >> To: GEOS Development List <geos-devel at lists.osgeo.org>
>> > >> Subject: Re: [geos-devel] End of Life Policy (EOL)
>> > >>
>> > >>
>> > >>
>> > >>> On Sep 12, 2022, at 8:12 AM, Regina Obe <lr at 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 at lists.osgeo.org
>> > >>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>> > >>
>> > >> _______________________________________________
>> > >> geos-devel mailing list
>> > >> geos-devel at lists.osgeo.org
>> > >> https://lists.osgeo.org/mailman/listinfo/geos-devel
>> > >
>> > > _______________________________________________
>> > > geos-devel mailing list
>> > > geos-devel at lists.osgeo.org
>> > > https://lists.osgeo.org/mailman/listinfo/geos-devel
>> > 
>> > _______________________________________________
>> > geos-devel mailing list
>> > geos-devel at lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/geos-devel
>> 
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel