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.

Regards,
Alex

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
confusion...
 
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
www.iktek.com
directory.apache.org





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