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]