On Sun, Sep 16, 2012 at 9:13 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi>wrote:
> I meant to say that after this is committed to 1.5, should we allow for > some polishing changes to get in after feature freeze even if they are > technically feature additions. > The kinds of changes you are describing can, I believe, be made after alpha (i.e. feature freeze). Major features like this one may very well need some additions/polishing after landing on master, once many more people start to experiment with them and find out what is needed/useful/etc. The intent of "feature freeze" is to stabilize the code base in general and not introduce side-effect bugs that may go unnoticed until after release if made late in a release cycle. For big brand-new features, sticking to a hard "feature freeze" line after alpha is more likely to be harmful than helpful, and I don't believe we've ever taken that sort of hard line for major features. It's even possible (though clearly not desirable) to introduce backwards-incompatible changes in the public interfaces for a new feature between alpha/beta/final. In this phase we're seeking to gather feedback from early adopters and experimenters, and not being able to incorporate that feedback into the in-progress release would be silly. Karen -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
