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

[Regina Obe]

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