On Wed, 24 May 2017 14:55:32 +0100 Ben Hutchings <ben@decadent.org.uk> wrote: > On Wed, 2017-05-24 at 13:14 +0000, Scott Kitterman wrote: > > On May 24, 2017 8:30:00 AM EDT, Ben Hutchings <ben@decadent.org.uk> > > wrote: > [...] > > > I've always understood that the exceptional cases justify > > > backporting a newer version that is currently only in unstable, > > > not an older version. > > > > > > I think we should have an additional exception for cases where it > > > becomes impractical to backport newer versions but a maintainer is > > > willing to support it with important fixes. But from what I've > > > read, that doesn't seem to be the case with Django 1.10. > > > > Other than breaking lots of user applications, no. > > > > Upgrading from 1.7 in Jessie to 1.10 is highly likely to break user > > code (even if it doesn't break things in the archive). > > That is a normal risk when using a non-stable suite. Jessie is stable and has 1.7. Stretch is the next stable and has 1.10. Going from 1.7 to 1.10 is not about non-stable suites. The missing suite is jessie-backports and the 1.8LTS. It so happens that whether you consider *-backports to be a non-stable suite or not, it is mandatory for this particular upgrade. Upgrading 1.7 to 1.10 without going via 1.8 will break all packages with django as a dependency. That is not a "normal risk", that is RC - causes data loss. It's bad enough that stable -> stable cannot work due to the version of django in jessie. Fine, we must live with that because we cannot get a django LTS into Jessie. I accept that, it's unfortunate, it's a timing thing and Debian cannot align releases with every possible upstream team, that's obvious. We'd never get a release out. It is quite something else to say that NOBODY can upgrade existing installations from jessie because the critical package in jessie-backports has been removed. This is not something which can be cherry-picked, it is a fundamental component of how *users* data is managed in the upgrade. Without 1.8 being available, Debian will be responsible for deliberately trashing user data at the upgrade to stretch. That is unacceptable for any reason, particularly for Policy which, again, must not be used as a stick to punish developers, let alone users. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpX1Vg5PaY6f.pgp
Description: OpenPGP digital signature