Add 3.14 to CI builds

[miguelgrinberg]

No description provided.

[pquentin]

Should we require 3.10 here then?

elasticsearch-py/pyproject.toml

Line 10 in a11aab5

requires-python = ">=3.9"

(My preference is to either support 3.9 or not, but you could convince me that keeping it a gray area like you usually do is a good idea.)

[miguelgrinberg]

I have no problem dropping 3.9. I didn't want to remove it in this PR though, because I assume we are going to backport this PR to 9.2, 9.1 and 8.19, which do need the 3.14 support, whereas dropping 3.9 only applies to the upcoming 9.2, since I suppose we don't want to also drop it in 9.1 and 8.19 patch releases.

[miguelgrinberg]

Also what you call the "gray area" to me means being nice to people by allowing the "requires-python" setting to lag a few releases. To me dropping support of a Python version and preventing people from installing on that version are different things.

So I'm 100% in agreement to drop 3.9. But I don't think it is necessary to bump this setting (which imho should still be 3.8), and I also don't feel necessary to run pyupgrade.

[pquentin]

To me dropping support of a Python version and preventing people from installing on that version are different things.

I don't get this part. All popular Python libraries I know (Django, Flask, FastAPI, urllib3, all scientific libraries that endorse SPEC-0, etc.) don't do this. They either support or don't support a given Python version. When they don't support it, they use requires-python to clearly signal it. Well, even microdot, which currently supports Python 3.8+ and still tests it in CI.

[miguelgrinberg]

Yes, for all my open source projects I'm at 3.8 right now. At some point I pyupgraded my code to 3.8, so I marked it as invalid for older releases, because it would obviously not work on them. This was not a decision related to what versions I support, but about what the version my Python code is at. Before settling on 3.8 I used 3.6 as baseline for my projects. All I'm planning to do now is to add 3.14 and drop 3.8 from the CI.

I do not feel it makes sense to prevent people from installing on 3.9, which went out of maintenance just days ago. I could be convinced to do this for the upcoming 9.2, but for patch releases on the older 9s and 8.19 it would be weird to do it.

[pquentin]

I'm happy to keep Python 3.9 support for Elasticsearch 8.19 and older 9s. However, I suggest dropping Python 3.9 on elasticsearch-py 8.19 in one year, when Python 3.15 gets released. (We kept Python 2.7 forever on elasticsearch-py 7.17, and this was painful, especially as Github Actions and libraries we depend on stopped working and we no longer had CI.)

Feel free to decide about elasticsearch-py 9.2. But if we drop 3.9 in CI, I'll be very tempted to start using pattern matching, parenthesized context managers, and X|Y types. Without necessarily realizing it.

[miguelgrinberg]

Okay, so this is what I propose:

• This PR will add 3.14 and will not remove 3.9. We'll back port it to 9.2, 9.1 and 8.19. We'll then release patches for 9.1 and 8.19 with 3.14 support.
• We'll add a separate PR that drops 3.9 for the upcoming 9.2 only. I feel a lot less strongly about keeping python-requires at 3.9 on a release that does not exist yet, so for this one release I'm fine bumping it to 3.10. I wouldn't pyupgrade the code immediately because I expect we will continue to back port things from time to time. Once the back port efforts slow down, we can run pyupgrade as well.

[pquentin]

Thanks! LGTM.