On Wed, Apr 20, 2011 at 3:56 PM, Paul McMillan <p...@mcmillan.ws> wrote:
> +1, I agree with Carl and Luke. The issue here is that for > non-showstopper bugs, users have probably found (or may even be > relying on!) the existing behavior. Keeping the "stable" branch more > stable by only changing things when there's a serious issue seems to > be a positive improvement. > Okay, I do think the regression issue makes a much stronger argument than the developer time issue. I'd be more comfortable if the policy stated that any new bugs introduced by the last release would be backported to that release. It's possible that "major functionality bugs in newly-introduced features" will equate to virtually the same thing, but I'm not clear what would constitute a major functionality bug (it sounds big, and like it might be a difficult criterion to meet). On the other hand, if we've all been living with a trivial bug since 1.0, we can probably live with it for just a little longer, and backporting certainly doesn't sound worth the potential risk of a regression. Cheers, Tobias -- Tobias McNulty, Managing Partner Caktus Consulting Group, LLC http://www.caktusgroup.com -- 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.
