Hi Pkl, On Monday, September 1, 2014 10:45:30 PM UTC+2, Pkl wrote: > > 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") >
At least three of those are security related, if you read the api stability docs you will see that we will not consider api stability if this affects a security issue. If that creates an issue for you, then by all means Django is not for you. As for the other changes, I'd say they are debatable, but caused serious confusion for users (I am helping out on IRC quite a bit, so I was really glad to see them changed). At the speed we release Django, this gives you roughly two years to change your code, I think this is reasonable enough to ask for. 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. > Oh, how so? They say to support Django 1.6 -- I doubt any of the above stated issues caused breakage there. > 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. > If we would break for purity, we'd be breaking a lot more… > 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" ? > For what? By the time we remove the feature from Django all apps should work with new Django versions. The older Django versions we are dropping support for by not keeping raw_post_data are no longer maintained and have __known__ and sometimes __easily__ exploitable security issues. What harm did the "markup" support in django, since no one expects such > extensions to be 100% secure anyway (no software on earth is) ? > No software on earth is 100% secure, but supporting something which has quite a few security implications and having to release security releases just for this component quite often isn't going to help. In the end users expect us to deliver secure code for known security issues in the third party libraries, this is not something we want to do. > 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 ? > You feel up to this? This should work perfectly fine as 3rd party app, just don't expect us to maintain compatibility for releases which aren't even under security maintenance anymore. 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 ? > Dunno, I usually never had problems. That said I only use relatively maintained apps, cause I want to be able to get bugs fixed "soonish". Cheers, Florian -- 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 [email protected]. To post to this group, send email to [email protected]. 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/ac4cd2d9-ed9b-4f9b-bd87-68ff5838ebcd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
