On Wed, 24 May 2017 17:21:21 +0300 Adrian Bunk <bunk@debian.org> wrote: > On Wed, May 24, 2017 at 03:06:07PM +0100, Neil Williams wrote: > >... > > 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. > > Why is no RC bug filed against the version in stretch? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847277 > >... > > 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 an upgrade path documented in the current draft of the > release notes, and a package in backports being required for an > upgrade is simply wrong. I disagree. We have taken great pains to ensure that our own documentation covers that jessie-backports is mandatory. I'm just trying to keep the plates spinning for our users. The Debian release notes are general and high-level. There will always be issues which cannot be covered in those notes which affect particular sections of users. We've tried to address that upstream for the benefit of our users. To be fair, our users are already all using jessie-backports as the support for their production systems and we test that particular setup intensively and constantly. We provide the assurance that jessie-backports is ready for production for *our specific use case* because we have the data to prove it. > Based on what you say the only real options are: > - ship both 1.8 and 1.10 in stretch As 1.10 is a developer release still, I'm not sure what that gives us. > - go back to 1.8 for stretch That is a short term fix but it is a fix for the immediate issue and for the dependency packages. 1.8LTS will drop out of security support upstream before the end of the stretch cycle. https://www.djangoproject.com/download/ Separately to this thread, I have been talking to the django maintainers in Debian, specifically Raphael, about providing the requested automation support to provide assurances on upgrading from 1.8 to the next LTS, 1.11 and on to the LTS+2, django 2.2LTS. That plan would also push developer releases of django into Debian experimental only. This means some changes for maintainers and upstream developers of packages depending on django to test their code with packages from experimental to head off any problems with the upgrade to the next LTS. However, this is workable. > As a side effect, either of these would permit 1.8 in jessie-backports > under the existing rules. It would, although I fear it is just storing up problems for the stretch -> buster cycle when we will need to try to go from 1.8LTS to 2.2LTS without having 1.11LTS available in the archive. Even having 1.11LTS in Buster as well as 2.2LTS isn't a straightforward solution because dependencies may need to have a new upstream release which works with 1.11LTS and then a separate release which works with 2.2LTS. Code that works without warnings from 1.8LTS is expected to work with 1.11LTS but not necessarily with 2.2LTS. I'm not sure how best to handle that one. It adds fuel to the flames that Debian ships out of date software by default. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpPNgO4Fxn6p.pgp
Description: OpenPGP digital signature