On Sat, Apr 17, 2010 at 6:02 AM, orokusaki <flashdesign...@gmail.com> wrote: > When I first started posting things on trac, I put up a request that > took me an hour to create, explaining the justification, as well as > putting the code in there. I didn't know how to make a patch, and I > went about it the wrong way, but regardless of that, I put a lot of > thought into it. Less than 3 minutes after I posted it, it was closed > and resolution set to `wontfix`. It was an extremely minor change that > didn't break any backwards compatibility, but I didn't follow the > right procedures, so wham, gone.
I'm going to stop you there. You repeatedly *asserted* that it was backwards compatible. We (Joseph and I) *repeatedly* told you that we didn't think it was, and we *repeatedly* told you to take the discussion to django-dev, and you *repeatedly* didn't, and we *repeatedly* pointed you at the contribution docs to tell you why we were saying you should take it to django-dev, and you *repeatedly* didn't... until you finally did, at which point, we demonstrated why your idea wasn't backwards compatible, and -- unless I'm mistaken -- you agreed. Please don't characterize what Joseph and I did as arbitrary or closed minded. > If the core team doesn't want to change the backwards compatibility > policy a tiny bit to accommodate faster paced code ( keeping up with > the Jone's and such, such as RoR 3.0 ), Django's backwards incompatibility policy doesn't mean *no change*. It means *no sudden change*. There are *many* examples in Django 1.2 alone of features that are being deprecated or altered in ways that will ultimately be incompatible. Code written for Django 1.0 won't run unmodified in Django 1.4 due to changes in admin registration, messaging, CSRF, and many other features. However, these changes are introduced as a series of progressive enhancements rather than sudden changes. This enables use to provide ample active warnings advising that code changes will be required. It also avoids the need to introduce "USE_NEW_BEHAVIOR" settings switches that require us to maintain two implementations in parallel and in perpetuity. We're open to any proposal to change the status quo - as long as it can be done gradually and gracefully. If you think hard enough, *most* problems can be fixed in this way. Those that can't are unfortunate warts, but that's the price we pay for having a stable platform. As Jacob said, that's not a claim that Django-style stability is "correct" - it's just the policy we have adopted based on our particular priorities. Yours, Russ Magee %-) -- 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.
