Add support for Python 3.12

[hugovk]

The second Python 3.12 release candidate is out! 🚀

Call to action

We strongly encourage maintainers of third-party Python projects to prepare their projects for 3.12 compatibilities during this phase, and where necessary publish Python 3.12 wheels on PyPI to be ready for the final release of 3.12.0.

Python 3.12.0 final is due out in two weeks: 2023-10-02.

See also https://dev.to/hugovk/help-test-python-312-beta-1508/

[deckar01]

Here are the changes I proposed: fe6b3a5

A little off topic, but is there a reason we are limiting the push trigger to tagged dev branches? The release job is already restricted to tags. It would be a nice assurance for contributors to know that their branches are stable before opening a PR (and maybe less noise for maintainers). bc08f5b

[lafrech]

A little off topic, but is there a reason we are limiting the push trigger to tagged dev branches? The release job is already restricted to tags. It would be a nice assurance for contributors to know that their branches are stable before opening a PR (and maybe less noise for maintainers). bc08f5b

I don't mind. I often allow CI on any branch push in my repos to fix things before a PR. I suppose the idea was to avoid 2 CI runs for a push in a PR but I'm realizing that once we enable it on push, we don't need it on PR, do we?

I always thought it didn't matter because most contributors push on their repo so only the few people here with push permissions would be affected. I'm realizing that this config may also affect contributors in their own repos. Right? In this case it's nice if CI runs in their repo before the PR is created. And if not, then we need to keep the PR trigger for external contributions.

[hugovk]

TODO for a repo admin:

• Remove 3.11 from required checks and add 3.12:

[hugovk]

A little off topic, but is there a reason we are limiting the push trigger to tagged dev branches? The release job is already restricted to tags. It would be a nice assurance for contributors to know that their branches are stable before opening a PR (and maybe less noise for maintainers). bc08f5b

Yes, this is a very good idea!

I pushed to dev to make sure I could test my changes before opening a PR. If I'd have wanted to create another PR, I wouldn't be able to test it on CI. I strongly believe contributors should use feature branches and should be able to test them first :)

[deckar01]

once we enable it on push, we don't need it on PR, do we?

idk. Does that rebase on the target branch or trigger the checks UI?

[lafrech]

All checks appear in CI checks UI: marshmallow-code/flask-smorest#551.

[hugovk]

Anything more I need to do here? Thanks!

[lafrech]

I guess not. I merged. I updated the required checks.

The allow-prereleases line is not needed anymore but it doesn't hurt and it's there for next time.

@deckar01

A little off topic, but is there a reason we are limiting the push trigger to tagged dev branches? The release job is already restricted to tags. It would be a nice assurance for contributors to know that their branches are stable before opening a PR (and maybe less noise for maintainers). bc08f5b

No problem with this. And it is probably better to keep both push and PR (for the rebase on the target branch).

Thanks @hugovk.