Apologies if this does not directly address your points, but I recently took over a Django site still running 1.1. I brought it fully up to 1.6 in under 2 hours work, including rearranging the project structure, updating settings, URL tags, import paths, switching to pip from buildout etc. Considering the version of Django this was written for is five years old I consider this an impressive achievement in backwards compatibility.
On another note, given Django's slow release cycle, deprecated features are visible if you run with warnings for between 18 months and 2 years before they stop working. I don't think it is unreasonable to expect a small amount of maintenance within these time frames. As the Django ecosystem is aging, it is sadly inevitable that some unmaintained projects will stop working. The only way Django could avoid this is complete stagnation which would kill Django much more than the small maintenance burden it imposes. Django remains one of the most stable web frameworks out there, but it must also continue to evolve or risk being IE6. On 2 Sep 2014 01:29, "Curtis Maloney" <cur...@acommoncreative.com> wrote: > Mostly for clarity and historical purpose, I'd like to expand on the > points you listed. > > Do not take this in any way as a dismissal of the issues you've raised. > > On 2 September 2014 06:45, Pkl <chambon.pas...@gmail.com> wrote: > >> >> Hello, >> >> I once was once lured to an ideal of long-term stability and >> retrocompatibility, by nice docs like this one : >> https://docs.djangoproject.com/en/dev/misc/api-stability/ >> >> But for some years, stuffs have actually been getting worse and worse, >> with each django release bringing its little crowd of nightmares. >> >> In random order, I stumbled upon: >> - removal of django.conf.urls.defaults >> > This was moved into django.conf.urls ... > > >> - removal of markup contrib lib (adios built-in RST support) >> > From memory, this was due to a security issue with the Markdown library > used. I, too , was hit by this, and ended up vendoring the tag library > into my project. > > >> - removal of request.raw_post_data (thus breaking about all existing >> webservice libs) >> > It was renamed to request.body, not removed. This is because it > represents the request body, no matter the HTTP method used. > > >> - lots of changes in mandatory settings, like allowed_hosts or DB conf >> format, >> > ALOWED_HOSTS was added as a security measure. > The only significant DB config format I can recall was adding multi-DB > support. Was there another? > > - future removal of the very basic "mimetype" argument from django objects >> (how many apps impacted ? quite MANY I guess) >> > IIRC this was renamed to content-type, since "mime type" is, in fact, for > email. > > >> - future removal of request.REQUEST (aka "we're not all consenting >> adults, let's remove all tools that people could misuse") >> > I remember the discussion for this. Primarily it was because it did cause > security issues, as well as being unclear as to which was looked up first- > GET or POST. > > As someone who has been using Django since 0.91... I've seen a lot of > change over the years, some more drastic than others. > > I don't get this relentlessness at breaking, for the sake of purity, all >> stuffs that are not actively maintained, yet could be perfectly working. >> > > Whilst it could be argued that, for instance, request.body and > requset.REQUEST were removed for "purity", it can also be said they were > removed for clarity (to avoid confusion) and safety (to avoid real security > issues). > > As for breaking unmaintained 3rd party apps... sorry, that's how the world > works. If you want that project to keep up to date with Django, either > incentivise the devlopers to do so, or contribute to them yourself. Such > is open source. > > >> What is easier, in a deeply dynamic language like python, than keeping >> retrocompatibility ? >> > I do like this idea... it should be possible to monkey-path in at least > some of these ideas. > Open a ticket, CC me, and I'll happily work with you on a PR. > If nothing else, we can make it a 3rd party app. > > >> Why not keep "raw_post_data" as an undocumented alias for "body" ? Why >> not keep "mimetype" as a silent alias for "content_type" ? >> > mimetype _was_ an alias for content_type for, IIRC, much longer than the > usual 2-release deprecation cycle. > > >> What harm did the "markup" support in django, since no one expects such >> extensions to be 100% secure anyway (no software on earth is) ? If code >> "purity" is wanted, then why not have all these monkey-patched from a >> builtin, but removable, "django.compatibility" util ? Why not wait for 2.0, >> to remove all compatibility aliases in one single shot ? >> > The current trend with contrib apps is to remove them if they'd benefit > from a more frequent release cycle - one not tied to that of core. > Howerver, I was a little surprised to see django.contrib.markup wasn't > moved to a django-maintained 3rd party app like some others were. Perhaps > open a ticket for that? > > >> >> The one killing features of django is its app ecosystem - being able to >> plug blogs, authentication systems, webservice generators, and all other >> kinds of applications, into this common framework, and benefit from the >> common auto-admin. And since all these apps don't evolve at the same rythm, >> retrocompatibility is IMHO a NECESSITY for django, not a LUXURY. Or isn't >> it ? >> > > >> >> Please don't kill the ecosystem, please respect the promises of >> api-stability that were once made..... >> > These promises have been kept. There is a LOT of code that could be > dropped or rewritten immediately if it weren't for the 2-relese deprecation > cycle. > > One of my PRs was rejected specifically because I hadn't implemented a > deprecation path. It would likely speed up template rendering, which I > think everyone agrees is desirable. > > -- > Curtis > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAG_XiSDBkbqrk0XFhdTFjMGsZmggE4RP31WjXQBew5wadm%2BOUg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAG_XiSDBkbqrk0XFhdTFjMGsZmggE4RP31WjXQBew5wadm%2BOUg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1GjYODHqr4FPimXFBfFadtP2J767d9y5Dvq7ahHDPAosg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
