-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
3.15.2 includes two undocumented breaking changes #9450
Comments
Not to get too philosophical, but this sort of thing is a major reason why people complain so much about the python packaging ecosystem. I know DRF does not state they use semantic versioning, but the documented versioning strategy does state for these "minor releases":
If it is not painfully obvious, the modern python package tooling landscape does rely heavily on adhering to something that resembles the meaning of semantic versioning, when using a major.minor.patch like scheme. It's even more important for such an ubiquidous project within the django ecosystem. I'm not trying to be mean, but I really hope that a project like DRF can lead by example. |
Damn, they just released 3.15.0 (it should be beta) because everyone was complaining and eagerly waiting for this release. The issue is that some pull requests should have been merged earlier since they promised to include them in this release. In fact, 3.15 was already supposed to drop support for older Python and Django versions. As far as I remember, during the discussion about ending support for Python 3.6, @tomchristie suggested a great idea: to stick to the supported Django releases and their corresponding Python versions at the time of the release. Everyone who follows the project and was preparing for the release has already updated their projects to the current versions. But I agree that there's nothing wrong with bumping the minor version every time a version of Python or Django is dropped. Especially since the project has moved into the stabilization phase and will be focusing more on maintenance rather than introducing new features. |
At a bare minimum, this should have been mentioned in the release notes for
the release. My primary issue is that this is a stealth change to anyone
who doesn't follow the internals of the development process. Plenty of
projects (annoyingly) don't follow semantic versioning.
It sounds reasonable to drop support in the next minor version after Django
drops support. This feels very much like how the Scientific Python
community has chosen to handle Python support, where numpy drives the
version of Python that everyone else supports, and they have a clear policy
on which Python versions they will support. This makes things easy for us
consumers of the library as we can know what to expect just by following
the consistent release schedules of a couple of tentpole projects.
…On Wed, Jun 26, 2024, 3:25 PM Sergei Kliuikov ***@***.***> wrote:
Not to get too philosophical, but this sort of thing is a major reason why
people complain so much about the python packaging ecosystem. I know DRF
does not state they use semantic versioning, but the documented
versioning strategy
<https://www.django-rest-framework.org/community/release-notes/#versioning>
does state for these "minor releases":
You should be able to upgrade between minor point releases without any
other code changes.
If it is not painfully obvious, the modern python package tooling
landscape does rely heavily on adhering to something that resembles the
meaning of semantic versioning, when using a major.minor.patch like scheme.
It's even more important for such an ubiquidous project within the django
ecosystem.
I'm not trying to be mean, but I really hope that a project like DRF can
lead by example.
Damn, they just released 3.15.0 (it should be beta) because everyone was
complaining and eagerly waiting for this release. The issue is that some
pull requests should have been merged earlier since they promised to
include them in this release. In fact, 3.15 was already supposed to drop
support for older Python and Django versions.
As far as I remember, during the discussion about ending support for
Python 3.6, @tomchristie <https://github.com/tomchristie> suggested a
great idea: to stick to the supported Django releases and their
corresponding Python versions at the time of the release.
Everyone who follows the project and was preparing for the release has
already updated their projects to the current versions. But I agree that
there's nothing wrong with bumping the minor version every time a version
of Python or Django is dropped. Especially since the project has moved into
the stabilization phase and will be focusing more on maintenance rather
than introducing new features.
—
Reply to this email directly, view it on GitHub
<#9450 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFFO7AT3ATINWAL37NV5DDLZJMISJAVCNFSM6AAAAABJ54PA5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJSGQ3TENBYG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Exactly. It's all well and good to put such policies and procedures in place, but the adherence to versioning norms should still take place. So folks that are not closely watching the communications around a project can still safely rely on the versioning scheme and the broader python ecosystem conventions to not blow things up. Thats all. Much love for DRF still. |
Ah okay, this will have been in error as a result of time pressure dealing with security related fix "Fix potential XSS vulnerability in browsable API." #9435 We haven't actually made any functional changes that prevent Python 3.6 / Django 3.0. See 1f2daaf Although the setup.py does exclude them. I think what we should probably do here to minimise disruption is...
|
So is it safe to upgrade to 3.15.2 if I'm still on Django 3.2? I can't tell from this conversation if it's actually a breaking change or not. And pip-audit is giving me a hard time about 3.14 |
In the 3.15.2 release, two very large breaking changes were included:
These were both breaking changes released as part of a bugfix release, which included a fix for a security issue, and which are not even documented in the release notes. Examining your past releases shows that you normally only do breaking changes like these ones in major and minor versions. At a minimum, the changelog should be updated to clearly call out that all of these releases are no longer supported.
The text was updated successfully, but these errors were encountered: