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.
Jesse McConnell wrote: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
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
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
Nothing can force us ;)
I don't see a need to do anything else unless your dealing with some
requirement being forced on you
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...
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
So basically, +1 for Alex proposal, assuming Jesse proposal fits in it.