[gdal-dev] Discussion - RFC 113: Build requirements for GDAL 3.14

[Greg Troxel]

Kurt Schwehr via gdal-dev <gdal-dev at lists.osgeo.org> writes:

> these versions, so please comment on the PR. Yes, an LLM generated the
> initial text, but I went through the whole thing and I think it's a good
> starting point.

I think the text is much longer than it would have been if human
generated, and thus an example of why LLM text shouldn't be allowed.
There are "this is normal" comments which are not helpful; the real
question about new min versions is the benefit to removing code that
copes with the older vs the pain on others.   e.g.

  *Python >= 3.11**: Python 3.8, 3.9, and 3.10 have reached end-of-life as of
  October 2026 (https://devguide.python.org/versions/). Updating the minimum
  supported Python version from 3.8 to 3.11 aligns GDAL with currently
  supported upstream Python releases and allows removing legacy compatibility
  workarounds in the SWIG Python bindings and test suite. Going forward, Python
  version support will be dropped when a version reaches end-of-life as
  described in https://devguide.python.org/versions/. Ubuntu 22.04 ships
  Python 3.10; the ``ubuntu-22.04`` CI configuration will obtain Python 3.11
  from another source (such as the deadsnakes PPA or conda).

Problems:

  - Sneaks in an auto-removal policy at official EOL.  That seems novel,
    a big deal, and not clearly wise.

  - excessively verbose "aligns".

  - does not (convincingly) show human judgement about the balance of
    the ongoing maintenance cost of the swig and test compat, vs the
    number of systems/users that will have to get non-base-python.

I am not saying "python requirement changes from >=3.8 to >=3.11" is a
bad change.  Even 3.11 is ancient and I find that I need 3.14 for Home
Assistant; anything that is 3.12 or older is too old for general use.
That sort of evalation is missing.

Overall, I'm not sympathetic to "I'm using LTS but I want to build new
gdal, and I expect to build new gdal".  That's a far larger issue, and
"does the project accomodate this kind of LTS usage at all" would be a
good discussion to have.  Similar to LLM text being extractive, LTS
system promulgating a culture of asking to be accomodation is an
unreasonable demand on maintainer time.  But projects seem to feel a
need to cater to this.


I suggest withdrawing this RFC at least until the LLM discussion
resolves.  I see it as an example of what's wrong with asking humans to
read LLM text.  It would be interesting to hear from others on that
point (separately from whether any particular version bump is a good
idea)