I think we're on the same page.  But I would add one more caveat, that Y "tries" to maintain API compatibility but there is no guarantee.  Z is what only guarantees API compatibility.

Thanks guys for the feedback.  I guess we should just go with this unless anyone has any objections until release time.


On Tue, Aug 11, 2009 at 4:34 PM, Emmanuel Lecharny <elecharny@apache.org> wrote:
Jesse McConnell wrote:
 o We have major.minor.micro numbers:
   - major number denotes massive architectural shift
   - minor number denotes feature introductions
   - micro number denotes bug fixes and optimizations without changes to interfaces, db formats etc

Why not just adopt the convention that people most commonly associate
with x.y.z?

X - breaks API, no assurance that you can use out of the box
Y - features api alteration but basic assurance of api compat
Z - bug fixes and maintenance releases
I don't think it's far from Alex proposal. As we don't have that much API exposed, we can say that Y also means the API is not broken. That probably will imply some @deprecated annotation, nothing much

I don't see a need to do anything else unless your dealing with some
requirement being forced on you
Nothing can force us ;)

fwiw your new one is far more inline with that basic idea and is much
better then your previous one dealing with .0 and .5 and that
This .5 stuff was introduced just as we wanted to move to Java 5, ŕ la Tomcat (remember the 5.0/5.5 versions. Looking back in anger, it was not really a good idea...

So basically, +1 for Alex proposal, assuming Jesse proposal fits in it.

cordialement, regards,
Emmanuel Lécharny

Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org