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
