Hi Tobias, my impression is that as a developer you can keep up with the changes pretty well and I don't think it's related to features being too costly to address. The main issue is really third-party code.
The only thing that I can currently think of as a comparison is the Angular 1.x branch: If there were breaking changes then there were very few and I don't think I've ever had issues with third-party plugins breaking due to upgrading an Angular 1.x release to a new "major" version. Yeah, I know that it's probably hard to compare the two frameworks and they rewrote everything from scratch in v2 and basically broke all code, but the 1.x parts were pretty well done at least :) Thinking about it I think the main issue is probably the high number of breaking interfaces: it's not like a bump from 1.10 to 1.11 changes two interfaces but it's a whole array of things in all kinds of components. This makes it very likely that an extension is affected by a breaking change. In addition to that I kinda feel like when using Django nowadays I can't really use it "as is", out of the box. 5-7 years ago when webdevelopment was about serverside templating & forms and very little JavaScript Django was almost perfect and you needed maybe 1 or 2 third-party libs to create a full website. Nowadays you need REST apis (DRF, CORS middleware) and also want to employ a CSP to lock things down. So TL;DR I suppose: * web development got more complex * Django did not move fast enough (IMHO) to support "modern" websites, responsibilities were moved to third-party libs * you therefore need more third-party libs which are usually (there are ofc exceptions) maintained worse than Django * there are a lot of breaking changes in interfaces each release so upgrading hurts a lot I know its a difficult problem so I don't know what the solution could/should be and I'm interested in opinions :) On 04/04/2017 11:43 PM, Tobias McNulty wrote: > Hello Bernhard, > > In my experience, Django strikes a good balance between adding new features > without moving so quickly that it's impossible to keep up. That being said, > third-party packages *can* vary widely in the speed with which they add > support for new Django versions after a new major release. > > What are some changes in Django over the past few releases that you felt > were too significant or costly to address? > > Tobias > > On Tue, Apr 4, 2017 at 3:15 PM, Bernhard Posselt <nukeawh...@gmail.com> > wrote: > >> Hi guys :) >> >> I'm maintaining a Django project that uses 6 apps: >> >> * djangorestframework, >> >> * django-parler (database translations), >> >> * django-allauth (openid & richer account settings) >> >> * django-recaptcha2 (simple recaptcha widget) >> >> * django-csp >> >> * django-cors-middleware >> >> Each time a new Django version is published it takes me at least a few >> weeks to upgrade. The reason is that each release breaks something in >> the apps that I use. Code that I wrote myself can usually be fixed >> pretty quickly. >> >> Personally I don't think that the number of dependencies is excessive. >> Furthermore I think that Django developers want to offload as much >> functionality as possible to thirdparty apps to improve maintainability >> so I doubt that I'm the only one with these issues. >> >> I know that deprecating and cleaning up things is *very* important to >> keep the framework alive however was it ever considered to tune down the >> frequency of breaking changes (like only remove features in a new LTS >> release)? >> >> Apart from that would it be possible to adopt semver? If you had >> followed semver closely, each 1.x release would have actually been a >> major release (e.g. 1.1 -> 2.0.0, 1.2 -> 3.0.0) and your point releases >> would need to contain three version numbers (e.g. 1.11.0 and not 1.11). >> >> I know that this versioning approach leads to very high version number >> in a short amount of time but that's essentially what Django does: >> breaking compat with each release :) >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/django-developers/7fde82bd-352d-9946-2cbc-699f04bd8773%40gmail.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f7d5f7a3-5445-08e7-0332-c9e4244378f2%40gmail.com. For more options, visit https://groups.google.com/d/optout.
