On Tuesday, March 10, 2015 at 6:01:28 PM UTC-4, Carl Meyer wrote: > > I sympathize with your situation, but Python 2.6 reached end-of-life on > October 29, 2013 (a year and a half ago now), and since then has been > unsupported and not receiving security updates. I don't think the Django > core team should set a precedent of extended support for Python versions > which are themselves unsupported by the core Python developers. > > If some Linux distributions are backporting Python security patches to > 2.6 themselves in order to extend its lifetime in their distribution, > perhaps it would make sense to ask them whether they will also backport > Django security patches to Django 1.6. (I would guess that some of them > may already be planning to do so, and may even have already done so for > previous Django releases in the past.) >
So, here's the basic problem. The distributions that are packaging python 2.6 are, basically Red Hat Enterprise Linux 6 and its clones (CentOS, Scientific Linux, Oracle, etc.) and SUSE Linux Enterprise Server 11. These two distributions make up a significant percentage of the enterprise deployment space. Neither of these distributions ships Django itself. For RHEL, the Fedora Project provides the EPEL add-on repository which is unsupported and *may* carry Django (though it has proven to be difficult, more on that in a minute). For SLES, there is OpenSUSE which acts similarly. These are community-sponsored and generally limited to only packaging what upstream provides, since with no corporate backing and engineering support, backporting patches from newer releases is unlikely to happen. The reason that neither of these distributions carries Django is specifically because of the short lifecycle of Django. The LTM releases (1.4 and the upcoming 1.8) are somewhat better aligned with the goals of enterprise distributions, but even those approximately three-year lifespans are significantly shorter than the ten years that the enterprise distributions want to maintain. So the chances of Django ever being shipped by a company capable of supporting it for that length of time is basically zero. (Not unless Django someday becomes a critical part of the standard Linux platform). In the Enterprise software space, there's an average of a two-year period between a new version of software becoming available and companies actually deploying it. This essentially means that an LTM release needs to be at minimum four years long, since it will require half of the supported lifecycle for consumers to convert over to it and they'll need the other half of it in order to migrate to the next version. (Also, most companies don't like constant migrations like this). So, I realize that Django 1.6 is not an LTM release, and so asking for an extension on it is probably unlikely to happen. I'd like to see 1.4 supported for at least the two-year migration period to 1.8, though (with 1.8 planned to accommodate the future migration as well). Also, is there any chance at all that python 2.6 support could be reintroduced to Django 1.8? That would make it plausible to migrate existing users to an LTM release at least, buying time to figure further plans out. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0d73f1d7-2e4f-4066-958c-5e25dd8b38a0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
