patch level releases and EOL of 3.0, 3.1

[Greg Troxel]

Sandro Santilli <strk at kbt.io> writes:

> We're still officially supporting releases as old as 3.0 (2018),
> and 3.6.0 was released before the patch-level of all branches,
> can we take the chance to EOL some branches after a last release ?
>
> According to https://postgis.net/development/versions_eol/#end-of-life-eol
> we're supposed to maintain minor versions for 2-4 years.

The text is

  The PostGIS project strives to support each minor version of PostGIS
  for 2-4 years after initial release and at the very least until the
  lowest PostgreSQL version supported by the PostGIS minor version is
  EOL’d.

The first part is clear:

  - During the 2 years after 3.x.0, there will be new 3.x.n as
    appropriate for severity of security/functionality bugs.
  - From 2-4 years, there might be.
  - After 4 years, there almost certainly will not be.

I find the second part not immediately understandable.  Looking at
3.1.0, released on December 18, 2020, it says pgsql >= 9.6.  9.6 was EOL
on November 11, 2021.  So if the min supported pgsql version at .0 time
is usually the oldest pgsql that is not EOL, this second clause will
never control postgis EOL timeframe.  I'd be in favor of simplifying the
statement and dropping it.

The real issue is limited time to maintain vs usefulness, and as always
the elephant in the room is commercial LTS distributions that expect
Free Software projects to accomodate them with free labor to support
their paying customers.   I may have mentioned before that I'm cranky
about that :-)

So if you take 4 years after release, 3.2.0 was December 17, 2021.
3.2.9 now makes sense, but anything after December 2025 does not.

As for 3.0 and 3.1, they're beyond their expiration date, and were it
me, I'd just not make any micros.  They've been supported for 4y beyond
release, and I don't see any reason to have a post-lifetime micro.  I'd
be in favor of just marking them EOL when the clock strikes 4 years,
with no need for a post-4y declared last.

Unless of course I'm confused and Red Hat etc. is paying for labor hours
to support old versions for the benefit of people choosing to run the
old software they provide.

> This would mean
> settign EOL flags to anything whose .0 was released before 2021, thus:
>
>   - 3.0 (2019)
>   - 3.1 (2020)
>
> So do you agree about doing the following releases ?
>
>   - 3.0.12 (and EOL)
>   - 3.1.13 (and EOL)
>   - 3.2.9
>   - 3.3.9
>   - 3.4.5
>   - 3.5.4

My take is 3.2 to 3.5 only, and 3.0/3.1 just mark EOL and be done with it.

Stepping back, I find the 4 year timeframe lengthy, as I am not really
seeing good reasons for people to refrain from ugprading postgis for
years.