option 1 is the "kill off 2.0, we moved it to 2.1 because there are a lot of code changes that had to be made" option

option 2 is the "let's make 2.1 right but piss everyone off while we release late release never"

option 1 is also the version numbers are cheap option

my experience with Hudson is that lots of releases are a good thing... however the problem with Hudson is deciding exactly how far to upgrade up to!

Sent from my iPod

On 29 Aug 2008, at 16:54, Ralph Goers <[EMAIL PROTECTED]> wrote:

I would like to point out that if we go with option 1 then the lifespan of 2.1.x will almost certainly be very short.

Stephen Connolly wrote:
can we hurry up and make a decision?

call a vote with the two options:

1. make 2.1.x be the replacement for 2.0.10... we're making no promises that there'll be a 2.0.10... the new features will now be in 2.2.x

2. spin a 2.1.0-m1 to get the 2.0.10-tc stuff "out there" and push for 2.1.0 in the next 4 weeks... any features not in 2.1 by then will have to wait for 2.2... after 4 weeks we start stabilizing until we have a 2.1.0 released

Sent from my iPod



---------------------------------------------------------------------
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]

Reply via email to