Reverting Django 3.1. to Django 3.0.6 raises "binascii.Error: Incorrect padding".

[אורי‎]

Hi,

I submitted this ticket today and it was closed:

https://code.djangoproject.com/ticket/31592  

I think Django should handle downgrading versions without raising exceptions. If objects (such as sessions) are invalid because of downgrading, they should be deleted automatically. It may happen that a user (website owner) downgrades Django and they would expect everything to keep working.

And I have a question: Will authenticated users still be authenticated after upgrading or downgrading Django to a different version? We use persistent cookies for 30 years and I don't want to log out users if they don't log out themselves or delete their cookies. I had a problem when upgrading to a previous version of Django (2.1) that session cookies stopped working in the other website I have (a different domain name), and it persisted until I defined SESSION_COOKIE_SAMESITE = None in settings [https://stackoverflow.com/a/59315164/1412564]. Until then my production websites didn't accept logins to the other website.

Thanks,

Uri.

אורי

u...@speedy.net

[Adam Johnson]

Hi Uri

Smooth upgrade-ability is hard.

Smooth downgrade-ability is even harder. It also imposes a tax on development, and can slow the roll out of new features as they can need roll out over multiple versions.

I agree both would be nice to have, but given the limited engineering resources for Django, I think it should focus on smooth upgrade-ability.

At least two of the major database servers that Django supports, PostgreSQL and MySQL, provide zero downgrade-ability. It's too hard for them to do. They focus on smooth upgrade-ability. Given that these are produced by bigger teams with vastly more resources, I don't feel confident Django can come near matching them.

Thanks,

Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeEvwJGZrA-x8z%3D--jUeXE66%3D6SDvbH6Q0242gKz%2BktLRQ%40mail.gmail.com.

--

Adam

[f.holop]

Adam Johnson - Fri, 15 May 2020 at 17:53:21

> At least two of the major database servers that Django supports, PostgreSQL
> and MySQL, provide zero downgrade-ability. It's too hard for them to do.

while this is now officially true for both MariaDB and MySQL,
until recentlyish it was possible to downgrade them after carefully
reading changelogs. This is now unsupported and even runtime errors
are generated.

AFAIK postgresql is/was always safe to upgrade/downgrade if staying on
the same major version.

having said that i think downgradability requires massive engineering
resources for very little return in case of a project like django.

long story short: never upgrade without reading changelogs, running the
testsuites, and deploying on test/staging first. It's not simply a
matter of bumping a number in requirements.txt, although it has happened
many times that no other changes were required :}

-f
--