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

[Daniel Baston]

Yes, it seems like more detail/decisions than we necessarily need. Maybe it
makes sense to update the minimum version of Python, but I'm not seeing any
problems/maintenance burden with 3.8, so why spend the time on it? When we
run into a problem with 3.8, as we eventually will, the case for updating
will be clear.

Is libnetcdf 4.8 a reasonable minimum version? I have no idea, and the
burden of doing the research to take a decision on that is probably greater
than just continuing along with the code we have.

There's also more to the decision than "what runners are available on
GitHub." An important number of GDAL users are coming from R, and are thus
limited by dependency versions available on the CRAN builders. I'd rather
not aggressively update our dependencies and have the result be that R
users continue to use GDAL 3.8, for example.

Dan

On Mon, Oct 19, 2026 at 7:36 AM Greg Troxel via gdal-dev <
gdal-dev at lists.osgeo.org> wrote:

> 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)
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20261020/552d64e7/attachment-0001.htm>