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

Upgrade Django version to 5.2 #1900

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

ulgens
Copy link
Contributor

@ulgens ulgens commented Jan 24, 2025

@bmispelon bmispelon marked this pull request as ready for review January 27, 2025 12:48
@bmispelon
Copy link
Member

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.

@pauloxnet
Copy link
Member

Considering that this upgrade doesn't seem to require any code change, I would like to deploy it in production this week.

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.

@pauloxnet
Copy link
Member

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.

BTW your commit is great ... starting using this new feature in the Django website is very good, also as an example.

@adamzap
Copy link
Member

adamzap commented Jan 27, 2025

As with all alpha and beta packages, this is not for production use.

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!

@ulgens
Copy link
Contributor Author

ulgens commented Jan 27, 2025

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?

@adamzap
Copy link
Member

adamzap commented Jan 27, 2025

@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.

@pauloxnet
Copy link
Member

... I believe it's important to test new Django versions with projects under the Django organization.

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.

... isn't it weird not to take that risk ourselves when we expect it from other users?

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.

@ulgens
Copy link
Contributor Author

ulgens commented Jan 27, 2025

@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?

@pauloxnet
Copy link
Member

@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 🙂

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. :-)

Do we have anything resembles that a staging environment, a remote setup that is not production?

I don't think so, but it's a question for the ops team.

Copy link
Member

@bmispelon bmispelon left a 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.

@pauloxnet
Copy link
Member

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

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