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.

[github-actions]

The backport to 8.19 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-8.19 8.19
# Navigate to the new working tree
cd .worktrees/backport-8.19
# Create a new branch
git switch --create backport-3103-to-8.19
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 1f43ab95f1a863f0f58b5818f272911d89060d3f
# Push it to GitHub
git push --set-upstream origin backport-3103-to-8.19
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-8.19

Then, create a pull request where the base branch is 8.19 and the compare/head branch is backport-3103-to-8.19.