Hi All, I would prefer 2.3.0 for this release for the reasons stated by Stefano and Søren. Beta or RC# I don't much care about, they mean different things to different people. Its more important to make our intent clear - a feature stable release, just shaking out the bugs.
If we're unsure that we can shake out the Derby bugs quickly we should pull this feature so that we can cycle through releases quickly to get to a final release soon. It would be better to add Derby in a subsequent 2.4.0 release in the not too distant future than hold up this release. I'ld say just my 2 cents, but as I've contibuted so little to this release, maybe 1 cent. Cheers and seasonal greetings to you all, -- Steve > -----Original Message----- > From: Søren Hilmer [mailto:[EMAIL PROTECTED] > Sent: 15 December 2005 11:05 > To: James Developers List > Subject: Re: Status, Release Candidates and Derby > > > I am on par with Stefano regarding the number scheme, and > also on a beta > release before a RC release. > > IMO we should save 3.0 for the more drastic upcomming changes, and > continue with 2.3.0 for this release. > > --Søren > > -- > Søren Hilmer, M.Sc., M.Crypt. > wideTrail Phone: +45 25481225 > Pilevænget 41 Email: [EMAIL PROTECTED] > DK-8961 Allingåbro Web: www.widetrail.dk > > On Thu, December 15, 2005 11:20, Stefano Bagnara wrote: > > Noel J. Bergman wrote: > >> Would people take a look at the current code and see if they feel > >> comfortable with a release candidate? Unless I encounter > a definitive > >> memory leak or other problem, I'd like to call a vote on a release > >> candidate. And since there are both configuration and functional > >> changes, > >> I'd suggest that v3 is perhaps the more appropriate > designation than > >> v2.3. > > > > I would better like a a 2.3b1 or 3.0b1 (beta release) > before the 3.0rc1. > > > > I'm not sure James is ready for release candidate: changes > I've done in > > the past months need to be tested by a wider audience to understand > > wether the users understand them or we need to change some > behaviour. > > > > Furthermore, I think that we could change our opinion (I > hope it doesn't > > happen but i'm not sure) about the "default" configuration (for mail > > stores, or anything else) after a beta cycle and I would > not be happy to > > change similar thing in release candidate cycles. > > > > Anyway I'm +1 for the release, soon! > > > > About the version numbers I'm +1 for a 2.3.0 and +0 for 3.0. > > > > We didn't publish a numbering rule, so it's a personal feeling. > > I like the 2.3.0 because current trunk has less changes > than the 2.1 to > > 2.2 step and it's not a "revolution". > > > > I would prefer to keep the 3.0 for the "next generation" (pojo, > > different container, different configuration style, much different > > behaviours). > > > > My preference is for an early 2.3.0 release and a fast move > to the 3.0. > > 2.3.0 (current trunk) fixes a lot of bugs from 2.2.0 and is > a due upgrade. > > > > Stefano > > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
