On Apr 4, 2006, at 14:15, Man-Chi Leung wrote:
> I read about tagging and branching in the book of "Version Control
> with Subversion"
>
> but there is nothing much regarding number convention and best
> practice on version numbering.
>
> 1) from subversion source tree, I also observed that it was
> evolving from 1.0.x -> 1.1.x ->1.2.x -> 1.3.x , etc
>
> 2) Eclipse community is using a term "Milestone". it was from 2.x
> M1 -> M2 ... -> M6 -> 3.x , etc
>
> 3) some others use a term "Release Candidate(RC)" , for example,
> 1.x rc1 , rc2 ... rc6 -> 2.x release , etc.
There are, of course, even more possibilities. Apple, for example,
uses a number-letter-number scheme (such as 8H14) for the internal
version numbers of several products, including Mac OS X, and then
assigns a "marketing" version number (such as 10.4.5) when it's ready
to be released. See:
http://en.wikipedia.org/wiki/Mac_OS_X#Versions
Many open-source software projects (e.g. the Linux kernel; graphviz;
cairo; pango; glib) adopt the idea that odd-numbered releases (2.5,
2.7, etc.) are unstable development versions, while even-numbered
releases (2.6, 2.8, etc.) are stable consumer releases. Other open-
source projects (e.g. Subversion) and most non-open-source projects
don't do this, instead either not giving development releases formal
names/numbers, or using a scheme like the release candidate or
milestone schemes you described.
> I am very puzzled on which convention to adapt and practise. any
> expert can help?
Which strategy you use is ultimately up to you and the expectations
your users might already have. The odd-number-is-development-branch
convention is pretty odd, for example, if you're not used to open-
source software, so if your users aren't, then you might want to
avoid that. I'm personally quite partial to the number-letter-number
idea, and intend to use it on my future projects, though when I
release something for public consumption, I'll be slapping on a
"marketing" version number too.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 4 16:37:16 2006