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 <[email protected]>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
