On Fri, Oct 15, 2010 at 2:06 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote:
> > > There is this crazy idea im my mind to mark CBVs API as > > "Beta" in 1.3 and put a big warning in the docs that it can change in > > backwards-incompatible was in 1.4. A precedence to this would be > > `databrowse`[1], but we could actually finish it this time ;). > > That thought has occurred to me in the past. My concern is how we > manage such an idea as a project. Backwards compatibility is a big > deal, and one of Django's big selling points IMHO. > > So - the question becomes how can we introduce a new feature, but give > people fair warning that they're using a feature that is subject to > change? Python's 'from __future__' is a really good approach to this, > IMHO -- i.e., an explicit opt-in to new features. There might be some > room to explore this sort of idea for Django. > > However, this isn't a decision we need to make right now. If we land > what we have, we can fiddle with it until the RC comes out; if we are > getting to that point and we're making API changes, we can look at our > options for providing adequate warnings. I'm with Russ here. I'd be wary of introducing exceptions to the current backwards-compat policy. It's relatively simple, many people are familiar with it, and I don't think it should change in surprising ways. The 'from __future__' idea is compelling and I like it but I would avoid introducing half baked features in a Django release. I expect most people like frameworks to "work". -- Ian http://www.ianlewis.org/ -- 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.
