On Mon, Apr 19, 2010 at 10:38 AM, David Zhou <da...@nodnod.net> wrote: > The specific number of point releases to remain compatible with can > probably be quibbled over, but I think the point is that maintaining > across the entirety of 1.x releases when point releases take this long > can be untenable for good forward momentum.
I'm pretty annoyed that you think that the policy is to maintain backwards compatibility "across the entirety of 1.x releases" because, well, that's not the policy. This is documented; see http://docs.djangoproject.com/en/dev/internals/release-process/. Quoting from there: """ Minor release (1.1, 1.2, etc.) [...] will contain new features, improvements to existing features, and such. A minor release may deprecate certain features from previous releases. If a feature in version A.B is deprecated, it will continue to work in version A.B+1. In version A.B+2, use of the feature will raise a DeprecationWarning but will continue to work. Version A.B+3 will remove the feature entirely. So, for example, if we decided to remove a function that existed in Django 1.0: Django 1.1 will contain a backwards-compatible replica of the function which will raise a PendingDeprecationWarning. This warning is silent by default; you need to explicitly turn on display of these warnings. Django 1.2 will contain the backwards-compatible replica, but the warning will be promoted to a full-fledged DeprecationWarning. This warning is loud by default, and will likely be quite annoying. Django 1.3 will remove the feature outright. """ So, yes, we're really *are* just quibbling over the specific number of releases that Django will be compatible with. A few people want just one stable release, but the core committers want two. So here's where I put on by BDFL hat: Django's backwards-compability policy will remain as quoted above. You think I'm wrong, and that's fine, and I don't expect to convince you otherwise. But ultimately it's my decision to make, and I'm making it. But for the record, I will explain why I feel so strongly about this: The best part of my job is that I get to talk to and meet so many people who're using Django. These folks span the glove, and they also span the gamut of software developers. In the last year, I've spoken to design agencies, data visualization companies, cloud computing experts, Enterprise IT developers, web 2.0 developers, web 1.0 developers, new media, old media, startups, Fortune 500 CTOs, venture capitalists, angel investors, bankers, attorneys, financial advisors, firemen, and more. The recurring theme -- the thing I hear over, and over, and over again -- is how much they love Django's stability and predictability. Over and over again I hear that software maintenance is a pain in the ass, and that Django makes it easier. If upgrades from 1.1 to 1.2 aren't easy, these developers tell me, then they won't be able to take advantage of new features. My evidence goes beyond anecdotal. Studies have shown that as much as 80% of software work is in maintenance, and, further, that much of that maintenance work is non-corrective (i.e. adding features). When software changes dramatically between releases, people get stuck on old versions, and this means they're unable to develop the features they need. So, once again, the policy will not change unless you can demonstrate overwhelming evidence that I am wrong. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
