You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Man-Chi Leung <ma...@gmail.com> on 2006/04/04 12:15:52 UTC
need advice on convention for version numbering!
hi,
sorry that I am a novice on versioning and SCM, but i really hope to
improve and pick up more on this area with SVN.
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.
I am very puzzled on which convention to adapt and practise. any
expert can help?
Regards,
manchi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: need advice on convention for version numbering!
Posted by Andy Levy <an...@gmail.com>.
On 4/4/06, Man-Chi Leung <ma...@gmail.com> wrote:
> thanks reply and advice from Andy & Ryan
>
> I learnt something today.
>
> I was just reading up the hacking guide on SVN site. http://
> subversion.tigris.org/hacking.html#release-numbering
>
> basically, I get the idea.
>
> btw, Java is my main working language and find out that maven has
> idea of versioning number+SNAPSHOT. anyone is practicing this
> snapshot scheme ?
>
> or does snapshot=RC?
When I see "snapshot" releases, these are typically untested,
"get-the-code-in-peoples'-hands" type releases which are often
unstable - basically a quick build from the trunk so that other people
can see the current state of development. Anything but an RC.
If you have questions about what a particular project's version
numbering convention means, you're best off talking to the people who
actually make those releases.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: need advice on convention for version numbering!
Posted by Man-Chi Leung <ma...@gmail.com>.
thanks reply and advice from Andy & Ryan
I learnt something today.
I was just reading up the hacking guide on SVN site. http://
subversion.tigris.org/hacking.html#release-numbering
basically, I get the idea.
btw, Java is my main working language and find out that maven has
idea of versioning number+SNAPSHOT. anyone is practicing this
snapshot scheme ?
or does snapshot=RC?
Regards,
manchi
On Apr 4, 2006, at 8:26 PM, Andy Levy wrote:
> On 4/4/06, Man-Chi Leung <ma...@gmail.com> wrote:
>> 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
>
> This is pretty consistent with most Open Source software, and quite a
> bit of commercial software for finished releases. The Linux kernel
> used to be one of the best examples of carefully-considered version
> numbering using this scheme, but this has slid in recent years.
>
>> 2) Eclipse community is using a term "Milestone". it was from 2.x
>> M1 -
>>> M2 ... -> M6 -> 3.x , etc
>
> These are releases made on the path to a new version. 2.x M1 was
> "based on version 2, milestone 1 on the path to 3.0". Milestone
> releases are typically not "production" releases, but rather
> significant checkpoints in the development process.
>
>> 3) some others use a term "Release Candidate(RC)" , for example, 1.x
>> rc1 , rc2 ... rc6 -> 2.x release , etc.
>
> Again, these are not "final releases", these are versions released by
> the project team to say "we think this is a solid build. If it passes
> the ultimate, final testing, we'll label it the final release."
> Subversion makes RC builds before a final release (I think there were
> 5 RCs before 1.3 was releaseD).
>
>> I am very puzzled on which convention to adapt and practise. any
>> expert can help?
>
> These are 3 different conventions for communicating three different
> "states" of the software.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: need advice on convention for version numbering!
Posted by Andy Levy <an...@gmail.com>.
On 4/4/06, Man-Chi Leung <ma...@gmail.com> wrote:
> 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
This is pretty consistent with most Open Source software, and quite a
bit of commercial software for finished releases. The Linux kernel
used to be one of the best examples of carefully-considered version
numbering using this scheme, but this has slid in recent years.
> 2) Eclipse community is using a term "Milestone". it was from 2.x M1 -
> > M2 ... -> M6 -> 3.x , etc
These are releases made on the path to a new version. 2.x M1 was
"based on version 2, milestone 1 on the path to 3.0". Milestone
releases are typically not "production" releases, but rather
significant checkpoints in the development process.
> 3) some others use a term "Release Candidate(RC)" , for example, 1.x
> rc1 , rc2 ... rc6 -> 2.x release , etc.
Again, these are not "final releases", these are versions released by
the project team to say "we think this is a solid build. If it passes
the ultimate, final testing, we'll label it the final release."
Subversion makes RC builds before a final release (I think there were
5 RCs before 1.3 was releaseD).
> I am very puzzled on which convention to adapt and practise. any
> expert can help?
These are 3 different conventions for communicating three different
"states" of the software.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: need advice on convention for version numbering!
Posted by Ryan Schmidt <su...@ryandesign.com>.
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