Hello, Hello,
My apologies for sounding rude, and for raising these issues so late. Yes, upgrading a project itself is a matter of a pair of evenings, the problem is with third-party libraries, and more again, plugins of third-party libraries (especially CMS-related). I've had to bundle a dozen of these with my app, because they didn't quite follow the pace of Django evolutions. Now of course, as you say, I might as well stabilize for some time on a LTS version, but as was said too, the next steps would also be much harder then. Or I could forget about modular apps, and go towards monolitic third-party apps instead... I felt that crucial variables like "request.REQUEST" or "raw_post_data" could stay aliased for much more than 2 minor versions (but undocumented and with warnings, of course), for teh sake of retrocompatibility. However if it's acknowledged, in the core team, that code maintainability and security would be hindered by keeping these artefacts, I can't argue that. Concerning the "rules of open source", I've yet to find a satisfying way to apply them regarding these "micro breaks". Imagine that project "myvideoplugin" is unmaintained (not handling PR) : unable to patch the original Repo, I'd have to fork it ; and unable to push results to the original pypi name, I'd have to create a separate myvideoplugin-pkl package on Pypi... that's quite some hassle for (often) a 10-lines patch. Thanks Curtis for the proposal, I was thinking about a django-retrocompat package indeed, however I realize that doing a decent job of retrocompatibility would be a much harder job than initially expected, since breaking changes are rarely a matter of simple aliases (https://docs.djangoproject.com/en/1.7/releases/1.7/#backwards-incompatible-changes-in-1-7) ; django-retrocompat wouldn't stand the expectations of users. But a minimal package dealing only with "renamed fields" would be doable, I'll have a look at it. 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/3317f347-d82b-4edd-90fd-16da41f5dc49%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
