-
-
Notifications
You must be signed in to change notification settings - Fork 987
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
Upgrade Django version to 5.2 #1900
base: main
Are you sure you want to change the base?
Conversation
916089e
to
94cfd76
Compare
Considering that this upgrade doesn't seem to require any code change, I would like to deploy it in production this week. I've pushed a commit that makes use of the new support for composite primary keys and allows us to delete a bunch of hacks, but it's not strictly required for the upgrade. |
Do you think it's safe to deploy in production the Django 5.2 alpha version? I thought we open this PR to check in advance for issue with 5.2 version and then upgrade after the stable release. I'm not strongly against the idea of merging this PR now, but I'm interested on other point of view. |
BTW your commit is great ... starting using this new feature in the Django website is very good, also as an example. |
From https://www.djangoproject.com/weblog/2025/jan/16/django-52-alpha-1-released/ 😉 Do you mean putting it on production to test, or upgrading production to Django 5.2 and keeping it there? I'm also excited about the Trac hacks being removed, but security or other issues could still be lurking as the community tries the release out. Maybe I'm too conservative on upgrades! |
I don't remember when was the last time I had issues with a pre-release version of Django. If all goes bad, I don't expect a worse scenario than a rollback. Also, I believe it's important to test new Django versions with projects under the Django organization. I understand why it sounds a bit risky, but isn't it weird not to take that risk ourselves when we expect it from other users? |
@ulgens I think the idea of testing a pre-release version is to run it on your dev and staging servers and especially running your test suite against it. |
It's ok to test as much as possible Django alphas version in project, and we ask Django developer to do the same locally or in pipelines.
Actually, we don't ask users to take the risk to use alpha version in production, in fact we warn them against this risk as @adamzap already pointed out. That said, we can decide to do that if we have strong motivation. |
@adamzap @pauloxnet I see. I do test Django versions in prod with active commercial products regularly, but I see that that is not common or expected 🙂 Do we have anything resembles that a staging environment, a remote setup that is not production? |
You are free to do so, and maybe 99.99% of the time it will be fine considering the stability of Django, but it is definitely not a good practice. :-)
I don't think so, but it's a question for the ops team. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the feedback everyone.
As an experiment, I deployed this PR in production for the last two hours and I'm happy to report that no errors were logged during that time 🎉
I've now un-deployed the change and we're back to running 5.1 again, but this makes me even more confident that we can deploy 5.2 once it's out.
Thanks for the test and for the feedback. 👍 I propose to create a stage environment for the future #1922 |
https://docs.djangoproject.com/en/dev/releases/5.2/