I have a preference for major.minor.point, provided there's agreement
about the
semantics of each e.g.
point -- bug fixes, no new functionality
minor -- new functionality that is compatible with all previous minor
releases for same
major release
major -- new functionality that introduce incompatible changes
Is there general agreement about what constitutes the stable "API" of
the application,
and what is implementation detail?
Shanti Subramanyam wrote:
Here are some guidelines for versioning :
http://incubator.apache.org/guides/releasemanagement.html#best-practice-versioning
I know Akara likes to use dates for release names and the guidelines
above certainly don't preclude it. I checked the existing incubator
projects and they're all using the /major.minor.point/ system of
versioning.
If we follow this convention, our first release will be 0.1.0. The
advantage to this is that if we make only minor changes and/or fix
bugs we can simply update the point (to 0.1.1). This naming gives the
user some idea of the level of changes that went in.
Does anyone else have a suggestion or opinion on the above ?
Shanti
--
============================================================================
,-_|\ Richard Smith Staff Engineer PAE
/ \ Sun Microsystems Phone : +61 3 9869 6200
[email protected] Direct : +61 3 9869 6224
\_,-._/ 476 St Kilda Road Fax : +61 3 9869 6290
v Melbourne Vic 3004 Australia
===========================================================================
