IMHO you are describing a release numbering scheme that has never be
used in past for James. I don't think we should ever discuss about this now.
As an example you deprecated fetchpop in 2.1 and added fetchmail in 2.2.
You changed a FULL component in a minor point release without even using
a deprecating step like I am proposing now.
That said I don't care of the number. If theway to work in peace is to
name the current trunk 5.0 I'm +1 to do so now ;-)
Stefano
Noel J. Bergman wrote:
Stefano Bagnara wrote:
IMHO if we'll ever want to make a 2.3.x release then we will use the 2.3
branch, otherwise from trunk we should create a 2.4.0 or a 3.0.0.
I'm not sure about trunk being v2.4 (as opposed to 3.0 - see below), but we'll
see.
And about the removal: we deprecate them in 2.3 and we remove them in
2.4. This makes sense to me, considering that we also have simple
substitutes for that.
I would not deprecate until we come to a major release. Not 2.3.1 or 2.4, but
a 3.0. We can call the releases whatever we want, but we have tried to stick
with something like:
X.Y.z: minor point release - bug fixes and minor enhancements
X.y: minor release - bug fixes and compatible enhancements
x: major release - major enhancements, and incompatible changes
The proposed spooling changes would be a major release. Adding JMX, Derby,
LDAP, would be a minor release. Fixing the key length when creating a new
table would be the X.Y.z type of minor point release.
Also, as undersirable as they might be, and even understanding that developers
have done a lot of testing, I would be more expecting bugs in an X.0 release
than in X.y or X.y.z. I would approach what we put into each release from that
perspective, to ensure that our releases meet expectations for risk aversion.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
