As a general point, and this is coming from an "enterprise" background with software that costs horrible amounts to purchase and maintain every year, I'm astonished at how good the quality of the Django migration notes are, and how many little details are there with "oh and if you do this then the combination won't work, here's what you do now". Combine that with virtualenv and security releases for older versions and I don't see how on earth the devs could do better on that front!
You'd be paying some IBM consultants for 3 months to get that level of expertise upgrading some of their products. Or 6 months for SAP. On Wednesday, 3 September 2014 21:45:27 UTC+2, Pkl wrote: > > 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/9bde2624-410d-4dc1-8ae9-cff33ac54d3d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
