Hello, While I generally agree with what other core devs have said regarding the examples you raised, I still find your feedback interesting because it reminds us that we iterate too quickly for at least some parts of the community.
It's unavoidable that some people will find the pace of Django's evolution too fast and others will find it too slow. We're trying to ease the pain of the former group by documenting thoroughly the changes in each release. I'm not sure I understand completely where your frustration comes from. The tone of your email seems disproportionate with the effort needed to replace all instances of "django.conf.urls.defaults" with "django.conf.urls". That takes about ten minutes, if you count the time to locate the information in the release notes and make the commit. Is it a case of death by a thousand cuts? Perhaps you could explain how you proceed when you need to upgrade Django in your projects? Are the release notes somehow lacking? Overall, I don't think we're going to change our pace — especially when it comes to security-related issues — but we can try to improve our communication around deprecations and removals. -- Aymeric. 2014-09-01 22:45 GMT+02:00 Pkl <chambon.pas...@gmail.com>: > > 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 > - removal of markup contrib lib (adios built-in RST support) > - removal of request.raw_post_data (thus breaking about all existing > webservice libs) > - lots of changes in mandatory settings, like allowed_hosts or DB conf > format, > - future removal of the very basic "mimetype" argument from django objects > (how many apps impacted ? quite MANY I guess) > - future removal of request.REQUEST (aka "we're not all consenting adults, > let's remove all tools that people could misuse") > > For example, I had great fun installing django + djangocms + zinnia + > cms_plugin_zinnia ; the probability of having no version mismatch between > all these components being more or less zero. > > And the future looks grimmer again, having a look at > https://docs.djangoproject.com/en/dev/internals/deprecation/. > > 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. > > What is easier, in a deeply dynamic language like python, than keeping > retrocompatibility ? Why not keep "raw_post_data" as an undocumented alias > for "body" ? Why not keep "mimetype" as a silent alias for "content_type" ? > 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 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..... > > regards, > Pkl > > -- > 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/6abfd1ee-0056-41c1-b079-f89f2f463cf5%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/6abfd1ee-0056-41c1-b079-f89f2f463cf5%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Aymeric. -- 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/CANE-7mVC6HDUCP6BCBPa0szy4xNWOk0V4GGnpFTU2Ngz7hHyzg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
