Hi Stephen, On 03/11/2015 06:28 AM, Stephen Gallagher wrote: > 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).
It certainly sounds like there's an opportunity here for someone to provide extra-extended security-backport support for certain Django releases (beyond the ~3.5 years we'll typically support an LTS release under current policy), to accommodate these enterprise users on dead (to upstream) Python versions. I remain quite unconvinced that this "someone" should be the Django core team. I think the core team's limited energies are better spent continuing to move Django forward. > 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). I think the current plan is for a 6-month support window for 1.4 after the release of 1.8. (Tim can probably correct me if I'm wrong - I know there was discussion about 3 months vs 6 months; I thought we settled on six.) > 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. I think that's extremely unlikely. Carl -- 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/55006656.7070305%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
