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.

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

Drop Python 3.8 and add Python 3.13 #445

Merged
merged 2 commits into from
Oct 26, 2024
Merged

Conversation

digitalresistor
Copy link
Member

As it says on the tin. Drop Python 3.8 and add Python 3.13

@digitalresistor digitalresistor merged commit fdd2ecf into main Oct 26, 2024
38 checks passed
@digitalresistor digitalresistor deleted the feature/support-py-3-13 branch October 26, 2024 21:53
kgaughan added a commit to kgaughan/waitress that referenced this pull request Oct 27, 2024
With Pylons#445, it no longer makes sense not to use `pkgutil.resolve_name` to
handle the importing of WSGI applications in the runner. There is one
very minor behavioural change in that `pkgutil.resolve_name` allows a
broader syntax for the imports, but supports the same syntax as the
existing code being removed, so this is a minor concern.

It has the pleasant side effect of removing some legacy code only
present for Python 2.6 that was missed when Python 2 support was
removed.
@davisagli
Copy link
Member

@digitalresistor Thanks for your maintenance efforts.

It would have been nice to have the drop of support for Python 3.8 noted with a major version bump and a mention in the release notes. I know Python 3.8 is no longer supported even by the Python community and don't have any objection to dropping support for it, but this caught at least one member of the Plone community who has an old site on Python 3.8 and tried to upgrade to waitress 3.0.1.

@mmerickel
Copy link
Member

@davisagli I think it can always be debated what constitutes a major version number and in strict semver (which waitress and most other pylons projects don’t follow too strictly) I probably agree with you but to be honest the python-requires metadata was correctly updated which is the main thing here. Anyone not respecting that metadata needs to get on board regardless of version numbers.

@stevepiercy
Copy link
Member

https://docs.pylonsproject.org/projects/waitress/en/stable/ has no mention of this change and needs to be updated. Can you confirm in which version this change was released, so I can put it under the proper heading? Sorry, I haven't been tracking this closely.

@mmerickel
Copy link
Member

You’re right it was missed in the changelog. Good eye. They were part of 3.0.1.

digitalresistor added a commit that referenced this pull request Nov 16, 2024
Add change log entry for #445 and update supported Python versions
hswong3i pushed a commit to alvistack/Pylons-waitress that referenced this pull request Nov 17, 2024
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Feb 5, 2025
3.0.2 (2024-11-16)

Security

- When using Waitress to process trusted proxy headers, Waitress will now
  update the headers to drop any untrusted values, thereby making sure that
  WSGI apps only get trusted and validated values that Waitress itself used to
  update the environ. See Pylons/waitress#452 and
  Pylons/waitress#451


3.0.1 (2024-10-28)

Backward Incompatibilities

- Python 3.8 is no longer supported.
  See Pylons/waitress#445.

Features

- Added support for Python 3.13.
  See Pylons/waitress#445.

Security

- Fix a bug that would lead to Waitress busy looping on select() on a half-open
  socket due to a race condition that existed when creating a new HTTPChannel.
  See Pylons/waitress#435,
  Pylons/waitress#418 and
  GHSA-3f84-rpwh-47g6

  With thanks to Dylan Jay and Dieter Maurer for their extensive debugging and
  helping track this down.

- No longer strip the header values before passing them to the WSGI environ.
  See Pylons/waitress#434 and
  Pylons/waitress#432

- Fix a race condition in Waitress when `channel_request_lookahead` is enabled
  that could lead to HTTP request smuggling.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants