Django LTS support time

432 views
Skip to first unread message

אורי

unread,
Aug 9, 2019, 3:31:25 AM8/9/19
to Django developers (Contributions to Django itself)
Django Developers,

I would like to know why Django LTS support time is 3 years. I think with Ubuntu LTS it's at least 5 years. We are using Django 1.11 for Speedy Net, which was released on April 2017, and I'm not sure we will be able to upgrade it before April 2020. There are changes which are not backward compatible, we will have to change some of our code if we upgrade Django, and some packages we are using, such as Django Crispy Forms, we have to use versions which don't support Django versions higher than 1.11 due to bugs in future releases (https://github.com/django-crispy-forms/django-crispy-forms/issues/889). Upgrading to the next LTS version (2.2) will take lots of time, and the end of support of 2.1 is December 2019. I want to release Speedy Net and Speedy Match to production soon, and I don't think we will be able to upgrade Django before 2020. It would help if there was 5 years support for each Django LTS version. What do you think?

Carlton Gibson

unread,
Aug 9, 2019, 3:40:38 AM8/9/19
to Django developers (Contributions to Django itself)
Hi Uri. 

I can’t see that we have capacity to extend the LTS support window. Even if we did, I’m not sure it’s a good idea. 

Your best bet is to get off the LTS and onto the latest major version, and then stay there. (As much work as that may look initially.)
It requires a commitment to upgrade every 9 months (with an 18 month window) but it really is the smoothest path.  

Re Crispy Forms, I’m fairly sure that if you can pin down the issue more precisely a fix would be quite easy. (It’s _always_ a template issue… — pin it down and you can override the shipped template in the meantime.) FYI they’ll be a new release in the Autumn there, before Django 3.0, so a PR before then would be super. 

Kind Regards,

Carlton


--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeEnNd2JyPZh1LfB%2BEM_2modh-rHp%3DqAT--RgkdYYbmn0Q%40mail.gmail.com.

Adam Johnson

unread,
Aug 9, 2019, 4:00:19 AM8/9/19
to django-d...@googlegroups.com
Hi Uri,

For everyone's convenience here's the documentation on the release process: https://docs.djangoproject.com/en/dev/internals/release-process/ , and the grid of supported versions in time: https://www.djangoproject.com/download/ 

The current release cadence was decided 4 years ago in DEP 4 https://github.com/django/deps/blob/master/final/0004-release-schedule.rst ‎

The current LTS cadence is a balance between a huge number of factors and players. Some would like it to be faster (like, say the world of JavaScript), and some would like it to be slower like yourself.

Here are a number of reasons I think Ubuntu can have a longer LTS than Django:
  • Ubuntu is a product by Canonical. They sell features on top of the OS to big clients and even sell extended support beyond LTS: https://ubuntu.com/esm#faq . Django is made by a charity and volunteers. Whilst we don't want to disrupt users with needless, there is also a limited amount of paid development time, by fellows, and we don't want to spend all of that backporting fixes.
  • The web moves faster than operating systems. Keeping Django releases a bit more frequent allows us to make sure we keep up with some aspects.
In my experience upgrading Django itself is not the hardest part of making a Python web app. You're right that there are bugs in external packages but typically I find compatibility PR's are welcomed and merged fairly quickly. django-crispy-forms is actually being maintained by Django fellow Carlton Gibson (in his spare time!) so I'm sure it's open to fixes for issues you see.

If you really care about long term LTS I believe you can install Django with apt on Ubuntu and they promise to backport all major CVE fixes into their version, though I recommend installing from pip

Hope that helps,

Adam

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeEnNd2JyPZh1LfB%2BEM_2modh-rHp%3DqAT--RgkdYYbmn0Q%40mail.gmail.com.


--
Adam

אורי

unread,
Aug 10, 2019, 12:19:07 PM8/10/19
to Django developers (Contributions to Django itself)
Thanks for your feedback. Eventually I found out that the Django Crispy Forms issue was a CSS bug in our CSS code. Anyway not related to Crispy Forms, it may take a lot of time and effort to upgrade Django for us, and I would prefer to keep using Django 1.11 as much as we can.

Kye Russell

unread,
Aug 10, 2019, 10:46:54 PM8/10/19
to django-d...@googlegroups.com
Just to throw in my two cents here. I work in an agency environment (lots of projects, very few staff) and we follow the LTS cycle for almost all projects. In my experience, jumping between LTS versions has - all things considered - not been that big of an issue for us. I still sometimes wake up in a cold sweat thinking about migrating from South to Django migrations, but that is a thing of the past for most people these days.

If I were working on a product with guaranteed ongoing work I’d just jump from major version to major version.

This is not meant to invalidate anyone else’s experience, but in my experience, the current deprecation process is sufficient. 

Kye Russell
Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

1337 Shadow Hacker

unread,
Aug 11, 2019, 8:31:27 AM8/11/19
to django-d...@googlegroups.com
Hi,

Lean Sensei practicing Django since 2008 here. Have tried all sorts of strategies, the one that offers the best effort/ROI ratio is to upgrade as soon as a new version comes out, even if that means contributing patches to dependencies and deploying forks until patches are released.

Best of luck

Patryk Zawadzki

unread,
Aug 12, 2019, 11:34:52 AM8/12/19
to Django developers (Contributions to Django itself)
W dniu sobota, 10 sierpnia 2019 18:19:07 UTC+2 użytkownik Uri napisał:
Thanks for your feedback. Eventually I found out that the Django Crispy Forms issue was a CSS bug in our CSS code. Anyway not related to Crispy Forms, it may take a lot of time and effort to upgrade Django for us, and I would prefer to keep using Django 1.11 as much as we can.

If upgrading looks like a lot of work today, it will be even more work in a year or two. Today a single dependency may be blocking you from the upgrade. Unless you have a contract with that dependency's maintainer, there's no guarantee of the situation ever improving. Soon you may not be able to add a dependency because it will require a newer version of Django. Anecdotal evidence: we have an internal policy of not supporting Django versions older than the current LTS unless we have someone paying for the effort.

As for the LTS policy: I don't think the current one cuts it. There are companies who are fine with upgrading once every two years but these companies could probably also do it every release or two. Then there are companies who want LTS support and these are often projects that need to run largely unmodified for five to ten years. I don't think the current LTS support helps them in any way. I think a better option (for both sides) would be if the foundation offered paid support for the releases nominated as LTS and if that support became more expensive every year (to compensate for having to maintain outdated software and to motivate the company to eventually allocate the budget to a proper upgrade). Paid support could also include features like early vulnerability disclosure and instructions for determining whether an issue was exploitable in a particular project.

Kye Russell

unread,
Aug 12, 2019, 7:58:01 PM8/12/19
to django-d...@googlegroups.com
IIRC such a service could threaten the DSF’a nonprofit / charity status. There are certainly third parties that offer this, including OS distributions that will backport security fixes as has been mentioned.  


Kye Russell
Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

1337 Shadow Hacker

unread,
Aug 12, 2019, 8:17:55 PM8/12/19
to django-d...@googlegroups.com
This reminds me when m$ agreed to sponsor an open source rewrite of one of their languages, and asked the devs to reproduce the same bugs that were in the closed source version, and then went on and sold that as a feature.

If there are people who are willing to maintain old versions for money that's fine, and could certainly be done under a non-profit / charity it's just about not keeping any benefit for the organization.

But it certainly goes against everything I would know about CI/CD (I mean as practice, not as tools).

1337 Shadow Hacker

unread,
Aug 12, 2019, 8:32:21 PM8/12/19
to django-d...@googlegroups.com
Actually I'm pretty sure it could be done even if DSF kept a profit, to re-inject it into other developments for exemple. AFAIK the major difference between non-profit and company is that you don't own it and as such you cannot take dividends out of it personally. IMHO everybody would benefit if DSF did more commerce and was stronger by that mean. I could sing an ode to commerce but that would be much off-topic.
אורי if you're looking for commercial extension you can certainly hire someone for that for the time being, Patryk's company seems to have willing developers, or hire someone to face the debt in your codebase, which Patryk's company will probably recommend for the same budget. Sorry for being so binary but unless another idea emerges from this topic...  it seems pretty cornered at this point, sorry for not being more helpful.

Best of luck

Josh Smeaton

unread,
Aug 14, 2019, 9:13:39 AM8/14/19
to Django developers (Contributions to Django itself)
I don't think the DSF has the capacity or the will to run a business offering paid support contracts.

But nothing is stopping an enterprising individual or company from doing so. All security patches are made public (eventually) and backporting fixes would be fairly low effort. https://railslts.com/ is prior art in this space.

I'm incredibly surprised no one has started up a business to do this for Django.

Pkl

unread,
Aug 17, 2019, 12:31:38 PM8/17/19
to Django developers (Contributions to Django itself)
Hello Uri,

my (unsurprising) two cents: this is less a problem with the time span of the LTS version, than of the API stability / upgrade ease / django compatibility (recently discussed in this thread).

In the current state of affairs, I advise you to upgrade your application to latest stable Django version, using a compatibility helper like my https://github.com/pakal/django-compat-patcher if you have compatibility conflicts with your codebase or your dependencies (if some compatibility fixers are missing for your own needs, please open an issue or contact me).

best of luck,

regards,
Pascal Chambon

Aymeric Augustin

unread,
Aug 17, 2019, 3:10:37 PM8/17/19
to django-d...@googlegroups.com
Hello,

Actually an individual attempted this for Django two years ago: https://web.archive.org/web/20170710090735/https://djangolts.com/

The website disappeared after a year. I don't know what happened. The quick death suggests there wasn't a ton of demand, though.

-- 
Aymeric.



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

James Bennett

unread,
Aug 18, 2019, 7:57:06 AM8/18/19
to django-d...@googlegroups.com
The main issue with an LTS is that there's no such thing as "long enough". Upgrading once every three years -- especially when the compatibility policy now is that if you run on the previous LTS with no deprecation warnings, you'll also be able to run on the next LTS without errors -- is not that much of a burden. But many organizations won't put in the time to do the upgrade until it's too late, and the length of the support period doesn't actually matter: an organization that can't manage an upgrade in 3 years also won't manage an upgrade in 5 years, or even 10 years, because the problem is not that the support period was too short. The problem is the organization's priorities, specifically the fact that doing maintenance work is not a priority.

A good example is Python 3 support. Python 3 was first released 11 years ago, and Django introduced support 6.5 years ago once Python 3.2/3.3 stabilized a lot of things. But there are still people today who haven't even *started* to upgrade to Python 3. It wouldn't matter if we gave them a hundred years -- it still wouldn't be "enough time" for them to upgrade.

I understand the arguments for *why* organizations do this -- which mostly come down to "it works right now, why should we spend time on something that isn't broken when we have real bugs to fix and features to add?" -- but unfortunately they usually end up learning, when it's too late, why they should have made time for maintenance work earlier. Giving them a longer support period won't change this. And a 3-year support period is a reasonable amount of time, especially given the work being done to make the LTS-to-LTS upgrade easy, and doesn't overburden the Django team with having to support ancient versions of the framework until the end of time.

With that said, there are Linux distributions which provide their own packaged version of Django, and which have longer support periods in which they will backport important fixes into their package even if the Django team isn't supporting that version anymore. Some of them charge money for this service, but if you need to buy a couple more years of support for an old version of Django, using one of those distributions may be your best option.

Levi Cameron

unread,
Aug 19, 2019, 2:38:46 AM8/19/19
to Django developers (Contributions to Django itself)
With that said, there are Linux distributions which provide their own packaged version of Django, and which have longer support periods in which they will backport important fixes into their package even if the Django team isn't supporting that version anymore.

Specifically:
  • The django package in Ubuntu is in main (ie maintained by a paid Canonical employee for the lifetime of the OS)
  • Django 1.6 was EOL in April April 2015 but Ubuntu 14.04 LTS was maintained until April 2019 (the last changelog was from Jan 2019 -- that's almost 4 years of backports). You can get an extra 3 years on top of that if you want to pay Canoncial.
  • Django 1.8 was EOL in April 2018 but Ubuntu 16.04 LTS is maintained until 2021 (and Canonical are still applying backports). As above, 3 years extra if you pay.
  • Django 1.11 is EOL life in April 2020 but Ubuntu 18.04 LTS is maintained until 2023, or 2028 (+5 years) if you want to pay.
  • This comes to a full 9 years of updates from first release for django 1.6 & 1.8, and 11 years for django 1.11

If Ubuntu isn't your thing then RHEL has a 10 year support guarantee (for free if you can tolerate the unpredictable lag between RedHat and CentOS releases).

If you don't want to be tied to a specific linux distribution then you also have ActiveState (which only depends on glibc).


In short, it's certainly not like there aren't already extended options if the default django 3 year policy is not enough. If someone really needs 6+ years of updates then it seems reasonable to me that they pay someone to do that work instead of expecting it from volunteer django maintainers.


Levi

Reply all
Reply to author
Forward
0 new messages