stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Black <>
Subject Re: _RWSTD_VER value on trunk
Date Wed, 12 Dec 2007 17:06:54 GMT
Martin Sebor wrote:
> This has been bugging me -- when someone checks out trunk, does a build and
> sends
> us build results, we have no way of telling that the build results are, in
> fact, for trunk and
> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is the
> same. I
> think we should change it so that the value is unique for each branch, or at
> least distinct
> from any release.
> Any suggestions for what would be a good value?

The following is my suggestion for a scheme for _RWSTD_VER:
Trunk feature branch: 0xFFFFFFxx
Major branch: 0xMMFF0000
Maintenance branch: 0xMMmmFF00

A trunk feature branch is a branch in subversion used for developing a
specific feature, which isn't ready for inclusion in trunk, but is major
enough that incremental testing is required.  An example could be the
implementation of concepts.  The placeholder 'xx' is a non-FF value,
unique to a feature branch.  If the number of feature branches exceeds
255, it will be necessary to reuse numbers, but this isn't a likely
occurrence in the near term.  These numbers should be issued in the
order the branches are created.

A major branch is a branch in subversion used for ongoing development of
a source compatible lineage.  The placeholder MM represents the major
version.  An example would be ongoing maintenance of the 4.x version of
stdcxx beyond 4.3, after the 5.0 release has been made.  In the case of
a 4.x maintenance branch, the version would be 0x04FF0000

Maintenance branches are an established concept, with the 4.2.x branch
being an example.  The placeholder MM represents the major version, with
the placeholder mm representing the minor version.  In the case of
4.2.x, the version would be 0x0402FF00.

My primary reason for using the 0xFF value as a placeholder (generally)
is because it is greater than any particular released version number.
This should allow checks which look for a specific version of the
library (either older or newer) to function correctly.  If someone
wanted to exclude the trunk from these checks, it would be possible to
simply perform a bitwise negation, and if the value of that negation is
0, it means the token references a trunk version.

--Andrew Black

View raw message