Perhaps, but 10 releases into a branch isn't a great place for innovation either.
On 6/12/08 10:40 AM, "Ralph Goers" <[EMAIL PROTECTED]> wrote: > I wouldn't be quiet so harsh. Of course stability is great and should > always be strived for. But so is innovation. > > For me the key is all about compatibility. If a feature can be added in > such a way that by default nothing changes, then we should lean towards > putting it in. If it cannot be done in a compatible way then it should > be targeted for a future release. But even then, that isn't an ideal > solution. Just because we let people know that 2.1 won't be compatible > doesn't mean people are going to like it. Some may want to stay on 2.0 > for quite a while, which means we should be prepared to support it long > past a 2.1 release. > > Brian E. Fox wrote: >> This is something that I think we don't want to put into 2.0.x at this >> point. We need to be focusing on stabilizing the issues and knocking out >> regressions, not introducing new places to hose people. >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
