Great to see everyone's opinion here.
My concern at this point is that we're not going to be able to stick to
the standard definitions of major and minor releases as we're still
evolving and it's likely that every release we make will introduce some
incompatibility.
It may also make sense to stick to a major number of '0' while in
incubator.
We already have plans to increase the size of the db - which will mean
schema changes. I doubt that we can complete this task before the first
0.1.0 release. So would it be okay to do a 0.2.0 release which will
involve re-creating databases due to incompatible schemas ?
Shanti
On 02/17/09 19:03, William Sobel wrote:
On Feb 17, 2009, at 4:55 PM, 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 ?
I have usually done major.minor.point, but I'm getting swayed by the
date since I have often found it difficult to have consistent consensus
on what constitutes a major, minor, and point release. It is necessary
we keep the meaning of the version number clear, eg. a point release
will only consist of changes to the code, no features or schema change
will be allowed, only bug fixes. A minor release will include minor
feature increases and minor schema changes with no additional tables.
etc...
Cheers,
- Will Sobel
