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

[Regina Obe]

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 <mailto: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 <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 <mailto: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 <mailto: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 <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 <mailto: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 <mailto: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 <mailto:geos-devel at lists.osgeo.org> 
> >>> https://lists.osgeo.org/mailman/listinfo/geos-devel
> >>
> >> _______________________________________________
> >> geos-devel mailing list
> >> geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org> 
> >> https://lists.osgeo.org/mailman/listinfo/geos-devel
> >
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org> 
> > https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org> 
> https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20220912/c6d9c458/attachment.htm>