You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2004/01/29 20:40:57 UTC
implementing version numbering
I'm rethreading this under "implementing version numbering", because
I'd like to distinguish it from the thread about goals, on which we
seem to have consensus. Please keep the implementation discussion in
the new thread, if it's not too much trouble, thanks.
-Karl
Branko Čibej <br...@xbc.nu> writes:
> John Peacock wrote:
>
> > kfogel@collab.net wrote:
> >
> >> Our interim releases ("0.x.y") are over, once 1.0.0 comes out. We
> >> need a new naming strategy. Using "1.1.0" as an example -- this
> >> applies equally well to any stable version triplet -- let's do suffix
> >> qualifiers:
> >>
> >> subversion-1.1.0-beta1.tar.gz
> >> subversion-1.1.0-beta2.tar.gz
> >> subversion-1.1.0-beta3.tar.gz
> >> subversion-1.1.0.tar.gz
> >>
> >> I think it's fairly clear that the "betaX" marker is leading *to* the
> >> release number on the left; have seen this strategy used by other
> >> software packages, anyway. We can use "alpha" instead of "beta" when
> >> we feel that tentative, but in general "beta" is probably fine.
> >
> >
> > I re-attach my proposed way to handle this (I used 'RC' instead of
> > 'beta', but you get the idea). It would even be possible to do
> > 'alpha', 'beta', and 'rc' using different negative values for
> > SVN_VER_MICRO (alpha = -1, beta = -2, rc = -3). This makes it very
> > easy for the release manager to just increment SVN_VER_SEQ instead of
> > hand-editing some #define for only those releases.
>
> I don't understand why you'd want to introduce a fourth level of version
> numbers. We use SVN_VER_TAG (and SVN_VER_NUMTAG) to mark prereleases.
> Here's how svn_version.h would look like on trunk after 1.0:
>
>
> Index: svn_version.h
> ===================================================================
> --- svn_version.h (revision 8533)
> +++ svn_version.h (working copy)
> @@ -48,14 +48,14 @@
> *
> * Modify when incompatible changes are made to published interfaces.
> */
> -#define SVN_VER_MAJOR 0
> +#define SVN_VER_MAJOR 1
>
> /** Minor version number.
> *
> * Modify when new functionality is added or new interfaces are
> * defined, but all changes are backward compatible.
> */
> -#define SVN_VER_MINOR 37
> +#define SVN_VER_MINOR 1
>
> /** Patch number.
> *
> @@ -73,26 +73,29 @@
>
> /** Version tag: a string describing the version.
> *
> - * This tag remains "dev build" in the repository so that we can always
> - * see from "svn --version" that the software has been built from the
> - * repository rather than a "blessed" distribution.
> + * This tag remains " (dev build)" in the repository so that we can
> + * always see from "svn --version" that the software has been built
> + * from the repository rather than a "blessed" distribution.
> *
> * During the distribution process, we automatically replace this text
> - * with something like "r1504".
> + * with something like " (dev build r1504)".
> + *
> + * On the release stabilization branch, this macro will be " (alpha)",
> + * " (beta 1)", " (release candidate 1)", ... and "" for final release
> + * versions.
> */
> -#define SVN_VER_TAG "dev build"
> +#define SVN_VER_TAG " (dev build)"
>
>
> -/** Number tag: a string indicating whether this is a released version.
> +/** Number tag: a more compact description of the version.
> *
> * This tag is used to generate a version number string to identify
> * the client and server in HTTP requests, for example. It must not
> - * contain any spaces. This value remains "+" in the repository.
> - *
> - * During the distribution process, we automatically replace this text
> - * with "" to indicate a baselined version.
> + * contain any spaces. This value remains "-dev" on trunk, and changes
> + * to "-alpha" or "-beta" on the release stabilization branch, and ""
> + * for final release versions.
> */
> -#define SVN_VER_NUMTAG "+"
> +#define SVN_VER_NUMTAG "-dev"
>
>
> /** Revision number: The repository revision number of this release.
> @@ -117,7 +120,7 @@
> #define SVN_VER_NUMBER SVN_VER_NUM SVN_VER_NUMTAG
>
> /** Complete version string */
> -#define SVN_VERSION SVN_VER_NUM " (" SVN_VER_TAG ")"
> +#define SVN_VERSION SVN_VER_NUM SVN_VER_TAG
>
>
>
>
>
>
>
> --
> Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: implementing version numbering
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
> Branko Čibej wrote:
>
>> I'd also like to address the issue of version numbers embedded in the
>> executables on Windows. Win32 uses a version number with four
>> components; however, they're all positive numbers, so your scheme can't
>> be easily translated to the Windows one.
>
>
> Also something I was not aware of. Why does the Win32 build need 4?
The Win32 build doesnt "need" 4, it's just that Windows _provides_ 4
components, and these are visible to the user via the file properties
dialogue in Explorer. I don't think there's a convention about using the
4th number (even Microsoft's components arent consistent in their
usage). Currently the Win32 build puts '0' there for development
versions, and the revision number of the release (whatever _that_ means)
for official builds.
>> How about leaving the patch number alone, and using the fourth component
>> to indicate the status:
>>
>> Value Meaning
>> 0 -dev
>> 1..100 -alpha1..100
>> 101..200 -beta1..100
>> 200..300 -rc1..100
>> 301.. released
>>
>> This way we can even use the revision number of the release for final
>> releases. :-) And we still keep the ascending sort order.
>>
>
>
> That's OK, I guess (though I hate to build any limit into the number
> of intermediate values). And why would we have any value for the
> fourth component on a released version? I would rather reserve 0 for
> that state (so the #if can suppress it from view).
We can't suppress the 4th number from the Windows file props dialogue.
That's why I currently put a (marginally meaningful) number there,
although that has it's problems because we're limited to 2^64 revision
numbers.
We'd never show the 4th number in SVN output or tarball names, of course.
> How about this:
>
> Value Meaning
> 0 released
> 1..500 -dev
> 501..800 -alpha1..300
> 801..900 -beta1..100
> 901..999 -rc1..99
>
> since we are likely to spend much more time at a -dev or -alpha status
> than -beta or -rc.
We don't need a range for -dev, because we won't make official
development snapshots -- once the code is stable enough to make a
snapshot worthwile, it's either alpha or beta.
> It still requires some preprocessor magic to render the output, but
> not too difficult.
Actually, it turns out it requires more than just preprocessor magic...
#define SVN_VER_STATE 103 /* Let's call this alpha3 */
#if SVN_VER_STATE==0
# define SVN_VER_TAG "-dev"
#elif SVN_VER_STATE > 300
# define SVN_VER_TAG ""
#elif SVN_VER_STATE > 200
# define SVN_VER_TAG "-beta" FIX_NUMBER(SVN_VER_STATE - 200)
Bam! There's no way I know of to implement FIX_NUMBER in the C
preprocessor so that it yields string representations of numbers from 1
to 100. The last thing I want is nine zillion #if/#elif pairs, one for
each value of SVN_VER_STATE.
We have to think of something else, sigh...
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: implementing version numbering
Posted by John Peacock <jp...@rowman.com>.
Branko Čibej wrote:
> The way I understand it, you're advocating using only numbers so that
> it's easier to write tools that will sort the version numbers correctly,
> right?
That's one reason. The other is that it is much harder to mess up incrementing
a number than it is to edit text consistently. I'm much happier if I can write
my user-visible output once and just let the machine work it out after I
increment the appropriate values.
And just to make it clear, I was never advocating that the negative component
would ever be visible except in the include file. All external representations
of the version would come from the preprocessed/human readable form (including
tags in the repository). The negative version components are just a means to an
end, nothing more.
>
>
> Since you're starting with a negative patch version, this means you have
> no way to represent prerelease versions of patch releases, e.g.,
> 1.0.1-dev.
I hadn't thought of that contingency. Hmmm...think...think...
> I'd also like to address the issue of version numbers embedded in the
> executables on Windows. Win32 uses a version number with four
> components; however, they're all positive numbers, so your scheme can't
> be easily translated to the Windows one.
Also something I was not aware of. Why does the Win32 build need 4?
>
> How about leaving the patch number alone, and using the fourth component
> to indicate the status:
>
> Value Meaning
> 0 -dev
> 1..100 -alpha1..100
> 101..200 -beta1..100
> 200..300 -rc1..100
> 301.. released
>
> This way we can even use the revision number of the release for final
> releases. :-) And we still keep the ascending sort order.
>
That's OK, I guess (though I hate to build any limit into the number of
intermediate values). And why would we have any value for the fourth component
on a released version? I would rather reserve 0 for that state (so the #if can
suppress it from view).
How about this:
Value Meaning
0 released
1..500 -dev
501..800 -alpha1..300
801..900 -beta1..100
901..999 -rc1..99
since we are likely to spend much more time at a -dev or -alpha status than
-beta or -rc. It still requires some preprocessor magic to render the output,
but not too difficult.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: implementing version numbering
Posted by Branko Čibej <br...@xbc.nu>.
John Peacock wrote:
> Branko Čibej <br...@xbc.nu> writes:
>
>>
>> I don't understand why you'd want to introduce a fourth level of version
>> numbers. We use SVN_VER_TAG (and SVN_VER_NUMTAG) to mark prereleases.
>> Here's how svn_version.h would look like on trunk after 1.0:
>>
>
> I think that each of the elements of a version should contain only
> numbers (internally), so that it is very obvious (if not rote) to know
> exactly what needs to change for each release. It also nicely handles
> the fact that the alpha, beta, rc releases are more closely related to
> the upcoming final version than they are to the previous releases.
> You need a fourth term because you are now tracking 4 things (the
> additional being whether you are talking about alpha, beta, or release
> candidate).
The way I understand it, you're advocating using only numbers so that
it's easier to write tools that will sort the version numbers correctly,
right?
> You only need to look at the current version, 0.37.0, to see that it
> does not hint that this might be the same code as 1.0.0. In essence,
> 0.37.0 is really 1.0.0 minus some small value. That's why in my
> second e-mail, I used these examples:
>
> 0.33.0 => 1.0.-2.0 => 1.0.0-beta0
> 0.33.1 => 1.0.-2.1 => 1.0.0-beta1
> 0.34.0 => 1.0.-2.2 => 1.0.0-beta2
> 0.35.0 => 1.0.-2.3 => 1.0.0-beta3
> 0.35.1 => 1.0.-2.4 => 1.0.0-beta4
> 0.36.0 => 1.0.-2.5 => 1.0.0-beta5
> 0.37.0 => 1.0.-1.0 => 1.0.0-RC0
Since you're starting with a negative patch version, this means you have
no way to represent prerelease versions of patch releases, e.g.,
1.0.1-dev. This is important, because the version number on the tip of
the stable branch (branches/1.0.x in our case) must be different from
the one in the tagged release. That is, the creation of a release tag
from the stable branch should be followed immediately by a change to
svn_version.h. For example, in HEAD, the version numbers on the various
branches and tags would be (where N is the hghest released patch version):
Branch Version
/trunk 1.1.0-dev
/branches/1.0.x 1.0.(N+1)-dev
/tags/1.0.N 1.0.N
...
/tags/1.0.0 1.0.0
I'd also like to address the issue of version numbers embedded in the
executables on Windows. Win32 uses a version number with four
components; however, they're all positive numbers, so your scheme can't
be easily translated to the Windows one.
How about leaving the patch number alone, and using the fourth component
to indicate the status:
Value Meaning
0 -dev
1..100 -alpha1..100
101..200 -beta1..100
200..300 -rc1..100
301.. released
This way we can even use the revision number of the release for final
releases. :-) And we still keep the ascending sort order.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: implementing version numbering
Posted by John Peacock <jp...@rowman.com>.
Branko Čibej <br...@xbc.nu> writes:
>
>I don't understand why you'd want to introduce a fourth level of version
>numbers. We use SVN_VER_TAG (and SVN_VER_NUMTAG) to mark prereleases.
>Here's how svn_version.h would look like on trunk after 1.0:
>
I think that each of the elements of a version should contain only numbers
(internally), so that it is very obvious (if not rote) to know exactly what
needs to change for each release. It also nicely handles the fact that the
alpha, beta, rc releases are more closely related to the upcoming final version
than they are to the previous releases. You need a fourth term because you are
now tracking 4 things (the additional being whether you are talking about alpha,
beta, or release candidate).
You only need to look at the current version, 0.37.0, to see that it does not
hint that this might be the same code as 1.0.0. In essence, 0.37.0 is really
1.0.0 minus some small value. That's why in my second e-mail, I used these
examples:
0.33.0 => 1.0.-2.0 => 1.0.0-beta0
0.33.1 => 1.0.-2.1 => 1.0.0-beta1
0.34.0 => 1.0.-2.2 => 1.0.0-beta2
0.35.0 => 1.0.-2.3 => 1.0.0-beta3
0.35.1 => 1.0.-2.4 => 1.0.0-beta4
0.36.0 => 1.0.-2.5 => 1.0.0-beta5
0.37.0 => 1.0.-1.0 => 1.0.0-RC0
Whatever the software displays to the user (the third column above), the
internal #defines are just numbers, and they change in easily automated ways.
I've been working on version objects in Perl for more than two years, and my own
version::AlphaBeta module does exactly this, so that the external representation
makes sense to humans, yet the internal representation is trivial for a machine
to perform either comparisons or to increment.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org