+1 for 2.3.0, +1 for Beta, +1 for Derby support in 2.4.0 if the
alternative is a delay.
Vincenzo
Steve Brewin wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
