james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Release contents, nomenclature, and deprecation
Date Sat, 10 Jun 2006 01:37:54 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message