I'm chiming in late here. There are pros and cons with both. The
major.minor is good, but has to be advanced manually. You cannot
automatically build it into the build/packaging process. The date can be
automatically generated. In order to take advantage of both, I suggest
having both mechanisms:
1. Use major minor as version number. I don't really care whether is
major.minor or major.minor.dot, but prefer not to have the dot for less
complexity.
2. Provide build date as part of the package. So instead of having
something like snv_102 we'll have Olio 0.1 b021909 or Olio 0.1.1 b 021909.
When we have a solid build, we'll just promote it to the official 0.1
and tag the repository with the build number. At least this is the way I
do it in Faban and allows me to easily track issues when they are
reported, even on non-final builds.
-Akara
Craig L Russell wrote:
The way everyone describes the major.minor.update releases in this
thread seem to be consistent.
I have no vote, but if no one objects, go for it.
Craig
On Feb 18, 2009, at 3:45 PM, Damien Cooke wrote:
Shanti,
This mechanism for labeling releases is extremely simple and widely
used. It provides people with an insight to the magnitude of the
change. But what needs to be determined is what constitutes a x.x.X
update and what constitutes an x.X.x update. In the past I have used
X.x.x update for interface changes x.X.x update for functional
enhancement and x.x.X for minor fixes.
Regards
Damien
On 18/02/09 11:25 AM, 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
William Sobel wrote:
A month sounds like it's doable, or should be! I think we already
have a planned release structure in the repo. Now for the toughest
question, how do we want to number the releases?
Cheers,
- Will Sobel
--
<email_banner.gif> <http://www.sun.com/eco> *Damien Cooke*
Open Scalable Solutions Performance
Performance & Applications Engineering
*Sun Microsystems *
Level 2, East Wing 50 Grenfell Street, Adelaide
SA 5000 Australia
Phone x58315 (x7058315 US callers)
Email [email protected]
Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:[email protected]
P.S. A good JDO? O, Gasp!
