Discussion:
Django 1.6's lifespan for security updates?
Christian Hammond
2015-03-10 19:44:07 UTC
Permalink
Hi,

According to
https://docs.djangoproject.com/en/1.7/internals/release-process/#supported-versions,
it appears that when Django 1.8 is released, Django 1.6 will no longer
receive security updates. I wanted to verify that this is true, and ask
whether there's a possibility of an extension on this timeframe.

I'll explain the situation we're in.

I manage Review Board, a code review tool currently in use by several
thousand companies/organizations, many of whom (according to stats we have
available) are on Python 2.6. From conversations we've had, many of these
companies are on LTS releases of Linux distributions that bundle Python 2.6
by default (including their mod_wsgi support, etc.), and are likely to
remain on it for the next year or two. Not to mention Amazon Linux and
other variants are all sticking with 2.6 for now as well.

This puts us in a difficult position where we are unable to drop Python 2.6
support without affecting a large number of installs out there (12% of our
base, or over 700 installs), meaning we haven't yet been able to make the
transition to Django 1.7/1.8 (as much as we want it). (It also makes the
lives of packagers easier who are trying to support software stuck in this
situation, from what I'm being told, as they're responsible for security
updates.)

As Django 1.6 is the last release to support Python 2.6, it would be very
nice to have a longer-term security release plan while companies transition
over. We see this happening, but slowly.

Is there any possibility of treating Django 1.6 as a special LTS release?

Thanks for considering :)

Christian

--
Christian Hammond
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com
--
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+***@googlegroups.com.
To post to this group, send email to django-***@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/1acdd537-26a3-456b-98a9-83db1085234f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Carl Meyer
2015-03-10 22:00:49 UTC
Permalink
Hi Christian,
Post by Christian Hammond
According to
https://docs.djangoproject.com/en/1.7/internals/release-process/#supported-versions,
it appears that when Django 1.8 is released, Django 1.6 will no longer
receive security updates. I wanted to verify that this is true, and ask
whether there's a possibility of an extension on this timeframe.
It is true, and I don't think it should be extended.
Post by Christian Hammond
I'll explain the situation we're in.
I manage Review Board, a code review tool currently in use by several
thousand companies/organizations, many of whom (according to stats we
have available) are on Python 2.6. From conversations we've had, many of
these companies are on LTS releases of Linux distributions that bundle
Python 2.6 by default (including their mod_wsgi support, etc.), and are
likely to remain on it for the next year or two. Not to mention Amazon
Linux and other variants are all sticking with 2.6 for now as well.
This puts us in a difficult position where we are unable to drop Python
2.6 support without affecting a large number of installs out there (12%
of our base, or over 700 installs), meaning we haven't yet been able to
make the transition to Django 1.7/1.8 (as much as we want it). (It also
makes the lives of packagers easier who are trying to support software
stuck in this situation, from what I'm being told, as they're
responsible for security updates.)
As Django 1.6 is the last release to support Python 2.6, it would be
very nice to have a longer-term security release plan while companies
transition over. We see this happening, but slowly.
Is there any possibility of treating Django 1.6 as a special LTS release?
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.)

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+***@googlegroups.com.
To post to this group, send email to django-***@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/54FF6991.7080909%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.
Avraham Serour
2015-03-10 23:07:18 UTC
Permalink
each django deployed on the machines with python 2.6 should already be on
the project virtualenv
I suggest to compile python 2.7 yourself and create the virtualenvs based
on the compiled python, no need to replace it system-wide
Post by Carl Meyer
Hi Christian,
Post by Christian Hammond
According to
https://docs.djangoproject.com/en/1.7/internals/release-process/#supported-versions
,
Post by Christian Hammond
it appears that when Django 1.8 is released, Django 1.6 will no longer
receive security updates. I wanted to verify that this is true, and ask
whether there's a possibility of an extension on this timeframe.
It is true, and I don't think it should be extended.
Post by Christian Hammond
I'll explain the situation we're in.
I manage Review Board, a code review tool currently in use by several
thousand companies/organizations, many of whom (according to stats we
have available) are on Python 2.6. From conversations we've had, many of
these companies are on LTS releases of Linux distributions that bundle
Python 2.6 by default (including their mod_wsgi support, etc.), and are
likely to remain on it for the next year or two. Not to mention Amazon
Linux and other variants are all sticking with 2.6 for now as well.
This puts us in a difficult position where we are unable to drop Python
2.6 support without affecting a large number of installs out there (12%
of our base, or over 700 installs), meaning we haven't yet been able to
make the transition to Django 1.7/1.8 (as much as we want it). (It also
makes the lives of packagers easier who are trying to support software
stuck in this situation, from what I'm being told, as they're
responsible for security updates.)
As Django 1.6 is the last release to support Python 2.6, it would be
very nice to have a longer-term security release plan while companies
transition over. We see this happening, but slowly.
Is there any possibility of treating Django 1.6 as a special LTS release?
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.)
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
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/54FF6991.7080909%40oddbird.net
.
For more options, visit https://groups.google.com/d/optout.
--
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+***@googlegroups.com.
To post to this group, send email to django-***@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/CAFWa6tLZTMxnLfg0m-Uxpr9S%2Bh%3DKDTWf%2BUSMYawa%2BcBUm7%2BypA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Stephen Gallagher
2015-03-11 12:28:23 UTC
Permalink
Post by Carl Meyer
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+***@googlegroups.com.
To post to this group, send email to django-***@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.
Andreas Kuhne
2015-03-11 12:53:01 UTC
Permalink
Post by Stephen Gallagher
Post by Carl Meyer
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
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
<https://groups.google.com/d/msgid/django-users/0d73f1d7-2e4f-4066-958c-5e25dd8b38a0%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
I think the main thing here is that python 2.6 has already reached end of
life in October 2013. That's 1 œ years ago! So opting for a dead version of
python to be used is not really the right way to go for the django
developers IMHO. I understand that python 2.6 is available via the package
manager in all of the enterprise distributions you are citing, however, it
should be possible (as someone already suggested) to compile at least 2.7
if not python 3 yourself and run them in virtualenvs (which you should be
doing anyway).

Maintaining old versions of python and several versions of the django
framework will only make things harder for the developers, which will
eventually just delay the development process, making vital security
releases take longer to be deployed. I understand the problems you are
having with python 2.6 not being supported, but frankly I don't see that to
be a django issue, but rather the enterprise server versions that are
running a python version past it's end of life.

Regards,

Andréas
--
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+***@googlegroups.com.
To post to this group, send email to django-***@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/CALXYUbmpPr6sDqQDQZ0iAUjK%3DJTmqo5mUL1jyDmGa2hFD_U1%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Bill Freeman
2015-03-11 13:51:51 UTC
Permalink
You should really decouple yourself from the distro's choices, saving
headaches in the future. Let me expand on Avraham's suggestion.

There is little difficulty in having more than one version of python on a
box. The main caution here is that the distrio's use of python might
depend on that python being a 2.6. That means that (ignoring PATH
modifications and use of virtualenvs) that typing "python" should get you a
2.6.. If your distro offers a 2.7 package, it is probably built so that
"python" gets you a 2.6, and "python2.7" gets you a 2.7, and the distor's
python based tools will continue to work (as) fine (as they ever did).

But I don't recommend using a distro 2.7 package, even if available. You
become subject to them doing something bizarre in an update. You have much
better control if you build it yourself. Avoiding replacing what you get
when you type "python" is easy enough: instead of "make install" use "make
altinstall", which does everything except "ln python2.7 python". Another
approach, used where I work, is to set the install path to a directory not
included in the default PATH setting, but then you can't simply type
"python2.7" (at least as root) to get a 2.7, or, more to the point, you
have to give a full path to virtualenv's -p flag. It takes some fiddling
(last time I did this) to be certain that you have all the necessary
development libraries (-devel on RPM based systems), since, for some,
python will still build, but some features won't be available. You may not
care about some of them now (readline support is a case in point) but they
don't hurt anything, and it's better than rebuilding later. Document what
you had to add for future reference.

Another requirement, if you are using mod_wsgi, is to re-link it against
your python. A given httpd - mod_wsgi install can only use one version.of
python. This, in practice, means building your own mod_wsgi, rather than
using a distro version. And if you're going this far, you may as well take
full control by building Apache httpd as well, though, so long as a
suitable development package is available, you may not need to.. It's not
as big a deal as it may sound.

If you're not using httpd/mod_wsgi, I can't offer any advice on what may be
required, since I haven't done my own installs of ngnx, etc.

Bill
Post by Andreas Kuhne
Post by Stephen Gallagher
Post by Carl Meyer
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
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
<https://groups.google.com/d/msgid/django-users/0d73f1d7-2e4f-4066-958c-5e25dd8b38a0%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
I think the main thing here is that python 2.6 has already reached end of
life in October 2013. That's 1 œ years ago! So