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

[Michael Sumner]

>
>
>
> 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.
>
>
It's still there (3.8.5) on macos.

The reason is response to libcurl:
https://github.com/R-macos/recipes/commit/e501d420ae1a46ad21fbed390d1b32bbbec42caf

Windows is fine
gdalraster::gdal_version()
[1] "GDAL 3.12.1 \"Chicoutimi\", released 2025/12/12"
[2] "3120100"
[3] "20251212"
[4] "3.12.1"

At some point I'll pursue the curl/gdal issue.

Cheers, Mike


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


-- 
Michael Sumner
Research Software Engineer
Australian Antarctic Division
Hobart, Australia
0438489030
e-mail: mdsumner at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20261021/ce495785/attachment.htm>