Hello, On Wed, 24 May 2017, Uwe Kleine-König wrote: > An alternative idea would be to have two separate (source) packages in > sid: django and django-lts. Then django-lts could be put into backports > and so maintained according to the backport policy.
I don't really like the idea of a separate source package, it means more security work, a lot of headaches for dependencies, upgrades, etc. In my opinion, the only good solution is the following: - maintain only LTS versions in unstable/testing - keep non-LTS versions in experimental Most of the (bigger) reverse dependencies of Django are interested in LTS versions (or are at least expected to work with the latest LTS version). Ideally we would make efforts to have a recent LTS version in new stable releases of Debian. The upstream schedule is a bit off with Debian's current schedule but they make a promise that if your application runs without any warning in LTS, then it will also run in LTS+1. So we should run plenty of checks on all applications available in Debian unstable with the current LTS. https://docs.djangoproject.com/en/1.11/internals/release-process/#internal-release-deprecation-policy With that in place, we could "safely" upload an LTS+1 pre-release in testing just before the freeze and negotiate with the release team to upload future point releases to stable. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/ _______________________________________________ Python-modules-team mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
