Hi Jon, Thanks for sharing your experience.
On 06/09/2015 07:25 PM, Jon Foster wrote: > I've been involved with Django, on and off, since v0.96 or so. I love > Django and think its the most productive way to build rich websites with > custom defined content types. Throw in Django-CMS and things get pretty > darn cool. > > I was thrilled when Django reached v1.0 since it came with the promise > of having a consistent and stable API, specifically a lack of backwards > incompatible changes, unless required by security concerns. > Unfortunately this promise is routinely violated for various excuses. > The bottom line is none of the apps I've written have been able to > survive any 2 point upgrades (v+0.2). Single point upgrades usually only > cause minor breakage. This last confuses me, so I'd like to get clarity. If "single point upgrades usually only cause minor breakage", then a two point upgrade is just two single point upgrades, one after the other, correct? Trying to upgrade directly from e.g. 1.6 to 1.8 without first going through 1.7 - by which I mean "having a fully working site that passes its tests with no deprecation warnings in 1.7" -- is definitely not recommended. So is the problem here that you've been trying to do a two-version upgrade directly, instead of version-by-version? Or that "upgrade with minor breakage" + "upgrade with minor breakage" = "too much for the project to survive"? > I realize the desire to grow things and I applaud it. But there is a > business issue here. I can't, in good conscience recommend Django as a > site platform to many of my small clients as they simply could not > afford the upkeep of a Django powered site. Especially if the site is > e-commerce related, where PCI, and responsible site operation, will > require that we stay current. In order to do so would require staying up > with the constant flow of backwards incompatible changes, combined with > the time and effort to reverse engineer and maintain contributed apps, > which aren't keeping pace either. > > With the current method of development on the Django platform, if I had > just a dozen sites of moderate complexity, it would become a full time > job just keeping them updated. Its complicated enough just finding the > apps that will actually work with each other to construct a site. But > the carefully constructed house of cards is virtually guaranteed to > break with the next update. > > So I ask, PLEASE return to and stick with the promise of API stability? > You promised and routinely point to that statement, while making > backwards incompatible changes. I want to spend more time working with > Django, but I need to know that my clients can rely on painless and cost > effective upgrades. > > Thanks for reading my complaint, > Jon > > -- > You received this message because you are subscribed to the Google > Groups "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/11e78690-2b5f-4e99-a377-62c19b74e333%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/11e78690-2b5f-4e99-a377-62c19b74e333%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" 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-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/557886D1.9030608%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
