On 13/06/2008, at 2:05 AM, Brian E. Fox wrote:
Perhaps, but 10 releases into a branch isn't a great place for
innovation
either.
I agree, but with that being the case we need a feature development
location that we are confident enough to release.
Given that, I think we need to move immediately on to releasing a 2.1
milestone from trunk and getting the significant existing changes in
front of users. It appears to me that there is not much standing in
the way of this.
I'll take a look over what we have open and post a summary today.
Cheers,
Brett
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]
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
