Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add Python 3.12 support #965

Merged
merged 4 commits into from Nov 13, 2022
Merged

Add Python 3.12 support #965

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
c88c595
Add Python 3.12 support.
freakboy3742 Nov 9, 2022
bb0fe0e
Add changenote.
freakboy3742 Nov 9, 2022
05b4b44
Use a -dev specifier for upcoming releases, and mark them experimental.
freakboy3742 Nov 10, 2022
9709e72
Restructured usage of experimental to improve task labeling.
freakboy3742 Nov 10, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
4 changes: 2 additions & 2 deletions .github/workflows/ci.yml
View file
Open in desktop
Expand Up @@ -67,8 +67,8 @@ jobs:
needs: [pre-commit, towncrier, package]
strategy:
matrix:
platform: ['macos', 'ubuntu', 'windows']
python-version: ['3.8', '3.9', '3.10', '3.11']
platform: ["macos", "ubuntu", "windows"]
python-version: ["3.8", "3.9", "3.10", "3.11", "3.12.0-alpha - 3.12.0"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will have to be updated after 3.12.0 is released, otherwise it won't pick up 3.12.1 etc. Can we instead use the "x.y-dev" syntax shown here? If so, we might as well apply it to every version.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-dev definitely makes sense for 3.12; I wasn't aware that syntax was an option.

I'm not convinced we want to adopt it for established releases, though. Looking at the tagged releases of Python, RCs of Python micro releases aren't that common; using 3.8-dev could communicate the impression that we're doing some sort of pre-release branch testing, which would only be the case if someone pushed a PR during the very limited window that an RC was available prior to the next final release.

runs-on: ${{ matrix.platform }}-latest
steps:
- uses: actions/checkout@v3.1.0
Expand Down
1 change: 1 addition & 0 deletions changes/965.feature.rst
View file
Open in desktop
@@ -0,0 +1 @@
Support for Python 3.12 was added.
1 change: 1 addition & 0 deletions setup.cfg
View file
Open in desktop
Expand Up @@ -20,6 +20,7 @@ classifiers =
Programming Language :: Python :: 3.9
Programming Language :: Python :: 3.10
Programming Language :: Python :: 3.11
Programming Language :: Python :: 3.12
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By declaring this. we're committing to fixing any Python 3.12 compatibility issues before each Briefcase release from now on, which should be manageable. But by adding it to CI the same way as the other versions, we would be forced to fix any Python 3.12 issues immediately, which could be inconvenient, and isn't necessary so early in the 3.12 release cycle.

Can we use the continue-on-error setting as shown here to make Python 3.12 failures non-fatal for now? Then we can make them fatal next year when it reaches RC status.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call. Fixed.

Programming Language :: Python :: 3 :: Only
Topic :: Software Development
Topic :: Utilities
Expand Down