16 ms·

The next release, Django 1.11, will be a long-term support release, and the one after that, Django 2.0, will no longer support Python 2. https://www.djangoproj

by Flimm 10y ago

The next release, Django 1.11, will be a long-term support release, and the one after that, Django 2.0, will no longer support Python 2. https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ I've grow to highly respect the Django project for its good documentation, its healthy consideration for backwards compatibility, security, steady improvements and all round goodness.

Galanwe 10y ago
Interestingly, I have the exact opposite view on Django. I hate their API and overall architecture, which I find to be the result of glueing features on top of features for many years. The internal code also is just like that: looks like every single method is riddled with out-of-band conditionals, which is the result of a community that prefers to hack things to work, instead of rethinking/refactoring.
- nsomaru 10y ago
  Could you give a description of some subsystem that has been architectured in this way, and then provide a concrete example of some methods that implement this pattern and why it is bad? We are users of Django, and it helps us to deliver projects, quickly. Interested to know how you think things could be improved.
  - stuaxo 10y ago
    Not sure what it's like now, but the insides of the admin used to be fairly terrible (generating HTML with strings for instance). There was a patch to change this to use templates, but it was rejected at the time as it slowed things down too much. FormWizard (which I hear doesn't exist now), was a nightmare to use for any sort of complex form - I tried to do just this and had to call many private methods. I understand metaclasses, but found the implementation of the ORM a little overcomplex. Trying to use the ORM API to work out the structure of the DB was a bit of a pain last time I tried (had to call private APIs).
    - samwillis 10y ago
      The core Django developers will (and have) freely admit that the admin interface implementation is a bit of a mess. There is an enormous amount of technical debt in it. It is however not a "core" part of Django and there are many alternatives. I think most people would agree that the correct long term solution to the admin interface is a complete rewrite, however the cost of doing so is too high. The html forms (used in the admin and everywhere else) have until now been generated from strings, however the next realise 1.11 (went to alpha yesterday) this has been changed to using the template tools.
      - throwawayish 10y ago
        While the admin code is kinda messy it's still easy to extend and customize. I'd be somewhat surprised if you could make something that dynamic and not be at least a bit messy. I myself and also other people I know have written quite some domain-specific applications almost entirely within the Django admin, which are as a result: secure, fast and easy to use, which in some cases are not just a bit better than the existing commercial tooling in these domains.
  - scrollaway 10y ago
    I disagree with the parent post; Django's codebase is overall pretty high quality. It definitely used not to be that way, though. But there are components that fit that. The entire form subsystem is awful to work with. Working with Javascript, webpack apps etc is a huge pain. The template syntax is also a failed design experiment, based on the premise that backend coders and template authors are not the same people and should not have the same level of power -- some of this is based on a good idea at its core, but Django ended up backtracking on that half-way and we're now with a very inconsistent template system and having to implement kludgy template tags and filters or new object methods that do not take parameters whenever we want to do anything remotely complex.. At this point I wish it'd just move towards supporting Jinja syntax (that is, alongside the regular syntax, not as a separate engine like it's currently possible).
    - acdha 10y ago
      > Working with Javascript, webpack apps etc is a huge pain. Could you explain what you mean? Django doesn't need to have any connection at all to your JavaScript stack.
      - scrollaway 10y ago
        If you want to use the Django staticfiles system (which you do - it's good and useful for non-js stuff as well), it kinda does. We use Django Webpack Loader for our sites: https://github.com/owais/django-webpack-loader https://github.com/owais/django-webpack-loader - This allows us to do `{% render_bundle ... %} which pulls in the appropriate script tag. But even then you can really feel how painful it is to work with, especially if you're adding typescript/scss to the mix. Solutions like Django Compressor are not really the right model anymore. And there's other issues as well. If you want to share settings between Django and the JS stack for example, you'll need to build your own pipeline for that. Building a form in react? Say goodbye to DRY on the form fields. Just, in general, Django predates JS apps being anything more than in-place enhancements and it shows.
        Daishiman 10y ago
- stuaxo 10y ago
  Last time I looked a lot of the insides were terrible. A project I was really impressed with the internals of is Celery (was expecting the worst having seen Django).
  - gtaylor 10y ago
    Things were a little bit hairy back in the 1.3 days, but they've done a ton of cleanup in modern times. I find the source much easier to follow these days. Many of the systems have been more clearly isolated to allow for replacement.
  - daenney 10y ago
    When was the last time you looked?
  - Ralfp 10y ago
    > Last time I looked a lot of the insides were terrible. But is it really? Speaking from personal experience it is easy to compare project with large featureset (and one with heritage) to one with scope on doing single thing and come with conclusion that smaller, focused codebase is more consistent and better implemented. At the end of day what matters is if those terriblenesses actually bite back: - is this code changed frequently? Does it need to be changed frequently? - is it written in a way that that makes fixes and improvement unbearably costful? - is it written in way that allows it to be put apart? How costful are those individual parts to improve? Django is large codebase that is worked on by different people and when time permits this, which means different parts differ in their age, practices, and ultimately, quiality. This eventually results in codebase that may give appearance of being messy. Joel Spolsky explains this nicely in his article about old and large codebases appearing as hairy and messy to developers: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Especially the part that follows below quote is valuable wisdom to keep in mind: > When programmers say that their code is a holy mess (as they always do), there are three kinds of things that are wrong with it.
  - jbkkd 10y ago
    Celery is an interesting one. The code looks well written, but I found contributing to be a real pain and documentation a mess, especially compared to Django's docs. Also, up until recently it was a one man job by Ask Solem. He's done incredible work making this project live and I am grateful for that. However I fear others have found it hard to maintain as well, slowing down progress on a very popular backend python project.
- danpalmer 10y ago
  I'd prefer to hold judgement on the internals of Django, however as a developer using the API, I also think it's a pleasure to use. There is a very high level of consistency, similar patterns used throughout, and the architecture results in a project structure that I can explain to a new developer who has never used Django before in minutes. I find few frameworks really scale in terms of structure and consistency, and working on a large web application, Django has proven to be very valuable for us. I'm curious, what's an example of a framework that you think has a better architecture, and in what context are you evaluating this?
  - creshal 10y ago
    Minutes is a bit of an understatement, but given the amount of complexity involved, the API is acceptably consistent.
  - ergo14 10y ago
    I would bet my horse on https://trypyramid.com/ https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.
    - tangue 10y ago
      Pyramid is great, but for years they had a ridiculous Iron Maiden- heavy metal like branding [0] which make it hard to sell it in the corporate world. I'm glad they evolved on this point. [0] http://keitheis.github.io/use-pyramid-like-a-pro/?full#Cover http://keitheis.github.io/use-pyramid-like-a-pro/?full#Cover
      - dkns 10y ago
        Not gonna lie, that cover(?)/artwork(?) looks pretty sweet. But I'm probably biased because I really like Iron Maiden.
        deleted 10y ago
        [deleted]
- ankitml 10y ago
  Not sure why you hate it? It is one thing to say Django is bad at x and then specify x and other thing is to say I hate Django because it its internals are shit and shoot your points like a machine gun. The second approach is not going to be helpful to anyone.
- raverbashing 10y ago
  > instead of rethinking/refactoring. And breaking backwards compatibility Django is not RoR. Their users rely on being able to upgrade seamlessly. The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them
  - surouaue 10y ago
    When you say "Django is not RoR", are you saying Django doesn't break backwards compatibility but Ruby on Rails does? If so, I have to very strongly disagree. It's almost mind boggling to me how much they break backwards compatibility as a framework. They usually warn users with a deprecation warning in one version and then they make the backwards incompatible change in the next version, but the sheer amount of these kind of changes makes upgrading an infuriating process. Especially when upgrading a large codebase.
    - BozeWolf 10y ago
      If you keep up with releases it usually is quite alright. Switching LTS versions causes a lot of drama indeed. But that is to be expected.
      - alasdairnicol 10y ago
        Agreed 1.4 LTS to 1.8 LTS was tricky, but future LTS to LTS upgrades like 1.8 to 1.11 should be easier. From 1.8 onwards, if your code runs without depreciation warnings in one LTS, then it should work on the next.
    - etatoby 10y ago
      > warn users with a deprecation warning in one version and then they make the backwards incompatible change in the next version That's exactly how _not_ to break backwards compatibility.
      - stefantalpalaru 10y ago
- yeukhon 10y ago
  I'd say if you hate it, you should propose the changes and how to refactor. There's only so much people can do and they certainly will benefit from first-time contributors who may have fresh ideas. Otherwise this is just plain complain and nothing else.
- metaphorm 10y ago
  In my opinion the user (where user is a web developer) facing layer of Django is among the best I've ever worked with. I will agree with you that the internals are very messy and hard to read and work with. The overall architecture is sound though. Tight coupling of core components, loose coupling of non-core components. Keep in mind that it's an "opinionated" framework though, so they do safely assume that if you're using django you want to be using its core components as a bundle, and will work with them as designed.
- sly010 10y ago
  I honestly think Django was a victim of it's own success. It started as a python (explicit is better than implicit) framework, but with a ruby-on-rails (convention over configuration) mentality. It became too successful too fast and it was too late to change things without breaking things. I remember it had all sorts of double import issues, a very limited (compared to jinja2) template engine and a very limited (compared to SQL Alchemy) ORM. It also coupled everything with everything, so it made it very hard to fix those issues. So as people grew into their projects, django got in the way. Most things were hidden in the framework lazily loaded so when you had some weird issues you didn't know where to look. I found it hard to digest that I couln't write a simple script that accesses the database without having to go through the entire autodiscovery process, hence incurring a 2-3 second delay on every execution. We also stopped upgrading at some point, because by the time django started supporting our special needs (especially around user handling), we already hacked around it, and upgrading would have been near impossible. The core developers probably knew all of these and they did more and more "de-magic-ification" with every version, and things are much better now, but we are stuck on an old version.
deleted 10y ago
[deleted]
coldtea 10y ago
>its healthy consideration for backwards compatibility Like screwing the huge majority of users with Python 2.x Django projects and having them update or be left behind?
- danpalmer 10y ago
  Well it has been on the roadmap for around 3 years, and they will have support for Python 2 in active maintenance for the next ~3 years, so I think this is actually fantastic support from the core team.
- gtaylor 10y ago
  It's going to be more and more of a burden for the developers to maintain compatibility with a 7-year old version of Python. I think this is smart and will help them focus on the road forward. Django 1.11 is an LTS release, so legacy stuff can stick with it and be just fine.
  - coldtea 10y ago
    >It's going to be more and more of a burden for the developers to maintain compatibility with a 7-year old version of Python. That's the version of Python that most of their users actually use -- with no major plans of mass updating.
    - pmontra 10y ago
      But the Python developers will abandon v2 sooner or later, so IMHO it's wise to start following the bilingual development guidelines https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef and eventually upgrade to v3. What are the alternatives? Forking the language or switching to another language look to have a higher cost.
      - tedmiston 10y ago
        Guide announced at PyCon last year that Python 2's end of life is extended to 2020. https://www.python.org/dev/peps/pep-0373/ https://www.python.org/dev/peps/pep-0373/
stefantalpalaru 10y ago
> its healthy consideration for backwards compatibility Is this a joke? They break backwards compatibility with every minor version, wasting tens of thousands of man-hours all over the world - time that, if we're honest, is not exactly billable. Most people don't upgrade because of this and keep on using vulnerable versions. It's good that they are trying to kill the project. It saves newbies from stepping into the tar pit.
- mcintyre1994 10y ago
  I don't have any projects using Django but they have an LTS model - surely you don't need to update to avoid being vulnerable? Just security patches?
  - Joeboy 10y ago
    For three years, if you release your project the day the LTS comes out.
    - paulddraper 10y ago
      How long do you expect? Java 7 had less than four years of support. Ubuntu Desktop LTS was three years, and starting with 12.04 it increased to five years. That's a language runtime and an operation system known for their stability, forming the bottom of very wide and deep ecosystems. Show me a web framework with a 3 year LTS, and I'm overjoyed.
      - desas 10y ago
        Symfony has 3 year LTS plus a year security support after. http://symfony.com/doc/current/contributing/community/releases.html#long-term-support-versions http://symfony.com/doc/current/contributing/community/releas...
    - mcintyre1994 10y ago
      Well the new model will have a new LTS every 2 years, with guaranteed compatibility as long as you didn't have any deprecation warnings. So you get 2 years to fix warnings, then a guaranteed working new version. I find it hard to believe anybody is doing anything better in this space.

by Flimm 10y ago

Galanwe 10y ago

Interestingly, I have the exact opposite view on Django. I hate their API and overall architecture, which I find to be the result of glueing features on top of features for many years. The internal code also is just like that: looks like every single method is riddled with out-of-band conditionals, which is the result of a community that prefers to hack things to work, instead of rethinking/refactoring.

nsomaru 10y ago
Could you give a description of some subsystem that has been architectured in this way, and then provide a concrete example of some methods that implement this pattern and why it is bad? We are users of Django, and it helps us to deliver projects, quickly. Interested to know how you think things could be improved.
- stuaxo 10y ago
  Not sure what it's like now, but the insides of the admin used to be fairly terrible (generating HTML with strings for instance). There was a patch to change this to use templates, but it was rejected at the time as it slowed things down too much. FormWizard (which I hear doesn't exist now), was a nightmare to use for any sort of complex form - I tried to do just this and had to call many private methods. I understand metaclasses, but found the implementation of the ORM a little overcomplex. Trying to use the ORM API to work out the structure of the DB was a bit of a pain last time I tried (had to call private APIs).
  - samwillis 10y ago
    The core Django developers will (and have) freely admit that the admin interface implementation is a bit of a mess. There is an enormous amount of technical debt in it. It is however not a "core" part of Django and there are many alternatives. I think most people would agree that the correct long term solution to the admin interface is a complete rewrite, however the cost of doing so is too high. The html forms (used in the admin and everywhere else) have until now been generated from strings, however the next realise 1.11 (went to alpha yesterday) this has been changed to using the template tools.
    - throwawayish 10y ago
      While the admin code is kinda messy it's still easy to extend and customize. I'd be somewhat surprised if you could make something that dynamic and not be at least a bit messy. I myself and also other people I know have written quite some domain-specific applications almost entirely within the Django admin, which are as a result: secure, fast and easy to use, which in some cases are not just a bit better than the existing commercial tooling in these domains.
- scrollaway 10y ago
  I disagree with the parent post; Django's codebase is overall pretty high quality. It definitely used not to be that way, though. But there are components that fit that. The entire form subsystem is awful to work with. Working with Javascript, webpack apps etc is a huge pain. The template syntax is also a failed design experiment, based on the premise that backend coders and template authors are not the same people and should not have the same level of power -- some of this is based on a good idea at its core, but Django ended up backtracking on that half-way and we're now with a very inconsistent template system and having to implement kludgy template tags and filters or new object methods that do not take parameters whenever we want to do anything remotely complex.. At this point I wish it'd just move towards supporting Jinja syntax (that is, alongside the regular syntax, not as a separate engine like it's currently possible).
  - acdha 10y ago
    > Working with Javascript, webpack apps etc is a huge pain. Could you explain what you mean? Django doesn't need to have any connection at all to your JavaScript stack.
    - scrollaway 10y ago
      If you want to use the Django staticfiles system (which you do - it's good and useful for non-js stuff as well), it kinda does. We use Django Webpack Loader for our sites: https://github.com/owais/django-webpack-loader https://github.com/owais/django-webpack-loader - This allows us to do `{% render_bundle ... %} which pulls in the appropriate script tag. But even then you can really feel how painful it is to work with, especially if you're adding typescript/scss to the mix. Solutions like Django Compressor are not really the right model anymore. And there's other issues as well. If you want to share settings between Django and the JS stack for example, you'll need to build your own pipeline for that. Building a form in react? Say goodbye to DRY on the form fields. Just, in general, Django predates JS apps being anything more than in-place enhancements and it shows.
      - Daishiman 10y ago
stuaxo 10y ago
Last time I looked a lot of the insides were terrible. A project I was really impressed with the internals of is Celery (was expecting the worst having seen Django).
- gtaylor 10y ago
  Things were a little bit hairy back in the 1.3 days, but they've done a ton of cleanup in modern times. I find the source much easier to follow these days. Many of the systems have been more clearly isolated to allow for replacement.
- daenney 10y ago
  When was the last time you looked?
- Ralfp 10y ago
  > Last time I looked a lot of the insides were terrible. But is it really? Speaking from personal experience it is easy to compare project with large featureset (and one with heritage) to one with scope on doing single thing and come with conclusion that smaller, focused codebase is more consistent and better implemented. At the end of day what matters is if those terriblenesses actually bite back: - is this code changed frequently? Does it need to be changed frequently? - is it written in a way that that makes fixes and improvement unbearably costful? - is it written in way that allows it to be put apart? How costful are those individual parts to improve? Django is large codebase that is worked on by different people and when time permits this, which means different parts differ in their age, practices, and ultimately, quiality. This eventually results in codebase that may give appearance of being messy. Joel Spolsky explains this nicely in his article about old and large codebases appearing as hairy and messy to developers: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Especially the part that follows below quote is valuable wisdom to keep in mind: > When programmers say that their code is a holy mess (as they always do), there are three kinds of things that are wrong with it.
- jbkkd 10y ago
  Celery is an interesting one. The code looks well written, but I found contributing to be a real pain and documentation a mess, especially compared to Django's docs. Also, up until recently it was a one man job by Ask Solem. He's done incredible work making this project live and I am grateful for that. However I fear others have found it hard to maintain as well, slowing down progress on a very popular backend python project.
danpalmer 10y ago
I'd prefer to hold judgement on the internals of Django, however as a developer using the API, I also think it's a pleasure to use. There is a very high level of consistency, similar patterns used throughout, and the architecture results in a project structure that I can explain to a new developer who has never used Django before in minutes. I find few frameworks really scale in terms of structure and consistency, and working on a large web application, Django has proven to be very valuable for us. I'm curious, what's an example of a framework that you think has a better architecture, and in what context are you evaluating this?
- creshal 10y ago
  Minutes is a bit of an understatement, but given the amount of complexity involved, the API is acceptably consistent.
- ergo14 10y ago
  I would bet my horse on https://trypyramid.com/ https://trypyramid.com/ when it comes to API consistency, I've updated my applications from 0.9 to 1.7 and that was a breeze. Over the years it was exceptionally great experience.
  - tangue 10y ago
    Pyramid is great, but for years they had a ridiculous Iron Maiden- heavy metal like branding [0] which make it hard to sell it in the corporate world. I'm glad they evolved on this point. [0] http://keitheis.github.io/use-pyramid-like-a-pro/?full#Cover http://keitheis.github.io/use-pyramid-like-a-pro/?full#Cover
    - dkns 10y ago
      Not gonna lie, that cover(?)/artwork(?) looks pretty sweet. But I'm probably biased because I really like Iron Maiden.
      - deleted 10y ago
        [deleted]
ankitml 10y ago
Not sure why you hate it? It is one thing to say Django is bad at x and then specify x and other thing is to say I hate Django because it its internals are shit and shoot your points like a machine gun. The second approach is not going to be helpful to anyone.
raverbashing 10y ago
> instead of rethinking/refactoring. And breaking backwards compatibility Django is not RoR. Their users rely on being able to upgrade seamlessly. The overall Api makes sense, there are some rough corners (yes Sites, I'm talking about you) the docs are ok once you get the hang of them
- surouaue 10y ago
  When you say "Django is not RoR", are you saying Django doesn't break backwards compatibility but Ruby on Rails does? If so, I have to very strongly disagree. It's almost mind boggling to me how much they break backwards compatibility as a framework. They usually warn users with a deprecation warning in one version and then they make the backwards incompatible change in the next version, but the sheer amount of these kind of changes makes upgrading an infuriating process. Especially when upgrading a large codebase.
  - BozeWolf 10y ago
    If you keep up with releases it usually is quite alright. Switching LTS versions causes a lot of drama indeed. But that is to be expected.
    - alasdairnicol 10y ago
      Agreed 1.4 LTS to 1.8 LTS was tricky, but future LTS to LTS upgrades like 1.8 to 1.11 should be easier. From 1.8 onwards, if your code runs without depreciation warnings in one LTS, then it should work on the next.
  - etatoby 10y ago
    > warn users with a deprecation warning in one version and then they make the backwards incompatible change in the next version That's exactly how _not_ to break backwards compatibility.
    - stefantalpalaru 10y ago
yeukhon 10y ago
I'd say if you hate it, you should propose the changes and how to refactor. There's only so much people can do and they certainly will benefit from first-time contributors who may have fresh ideas. Otherwise this is just plain complain and nothing else.
metaphorm 10y ago
In my opinion the user (where user is a web developer) facing layer of Django is among the best I've ever worked with. I will agree with you that the internals are very messy and hard to read and work with. The overall architecture is sound though. Tight coupling of core components, loose coupling of non-core components. Keep in mind that it's an "opinionated" framework though, so they do safely assume that if you're using django you want to be using its core components as a bundle, and will work with them as designed.
sly010 10y ago
I honestly think Django was a victim of it's own success. It started as a python (explicit is better than implicit) framework, but with a ruby-on-rails (convention over configuration) mentality. It became too successful too fast and it was too late to change things without breaking things. I remember it had all sorts of double import issues, a very limited (compared to jinja2) template engine and a very limited (compared to SQL Alchemy) ORM. It also coupled everything with everything, so it made it very hard to fix those issues. So as people grew into their projects, django got in the way. Most things were hidden in the framework lazily loaded so when you had some weird issues you didn't know where to look. I found it hard to digest that I couln't write a simple script that accesses the database without having to go through the entire autodiscovery process, hence incurring a 2-3 second delay on every execution. We also stopped upgrading at some point, because by the time django started supporting our special needs (especially around user handling), we already hacked around it, and upgrading would have been near impossible. The core developers probably knew all of these and they did more and more "de-magic-ification" with every version, and things are much better now, but we are stuck on an old version.

deleted 10y ago

[deleted]

coldtea 10y ago

>its healthy consideration for backwards compatibility Like screwing the huge majority of users with Python 2.x Django projects and having them update or be left behind?

danpalmer 10y ago
Well it has been on the roadmap for around 3 years, and they will have support for Python 2 in active maintenance for the next ~3 years, so I think this is actually fantastic support from the core team.
gtaylor 10y ago
It's going to be more and more of a burden for the developers to maintain compatibility with a 7-year old version of Python. I think this is smart and will help them focus on the road forward. Django 1.11 is an LTS release, so legacy stuff can stick with it and be just fine.
- coldtea 10y ago
  >It's going to be more and more of a burden for the developers to maintain compatibility with a 7-year old version of Python. That's the version of Python that most of their users actually use -- with no major plans of mass updating.
  - pmontra 10y ago
    But the Python developers will abandon v2 sooner or later, so IMHO it's wise to start following the bilingual development guidelines https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef and eventually upgrade to v3. What are the alternatives? Forking the language or switching to another language look to have a higher cost.
    - tedmiston 10y ago
      Guide announced at PyCon last year that Python 2's end of life is extended to 2020. https://www.python.org/dev/peps/pep-0373/ https://www.python.org/dev/peps/pep-0373/

stefantalpalaru 10y ago

> its healthy consideration for backwards compatibility Is this a joke? They break backwards compatibility with every minor version, wasting tens of thousands of man-hours all over the world - time that, if we're honest, is not exactly billable. Most people don't upgrade because of this and keep on using vulnerable versions. It's good that they are trying to kill the project. It saves newbies from stepping into the tar pit.

mcintyre1994 10y ago
I don't have any projects using Django but they have an LTS model - surely you don't need to update to avoid being vulnerable? Just security patches?
- Joeboy 10y ago
  For three years, if you release your project the day the LTS comes out.
  - paulddraper 10y ago
    How long do you expect? Java 7 had less than four years of support. Ubuntu Desktop LTS was three years, and starting with 12.04 it increased to five years. That's a language runtime and an operation system known for their stability, forming the bottom of very wide and deep ecosystems. Show me a web framework with a 3 year LTS, and I'm overjoyed.
    - desas 10y ago
      Symfony has 3 year LTS plus a year security support after. http://symfony.com/doc/current/contributing/community/releases.html#long-term-support-versions http://symfony.com/doc/current/contributing/community/releas...
  - mcintyre1994 10y ago
    Well the new model will have a new LTS every 2 years, with guaranteed compatibility as long as you didn't have any deprecation warnings. So you get 2 years to fix warnings, then a guaranteed working new version. I find it hard to believe anybody is doing anything better in this space.