Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4762BA2C.9090100@roguewave.com>
Date: Fri, 14 Dec 2007 10:15:24 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: _RWSTD_VER value on trunk
References: <4746236E.2090008@roguewave.com>
 <14289920.post@talk.nabble.com>	 <4760152E.3000408@roguewave.com>
 <4761A304.2030509@roguewave.com>
 <2494433f0712132122n25d80894lbe8495fccc843e4f@mail.gmail.com>
In-Reply-To: <2494433f0712132122n25d80894lbe8495fccc843e4f@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mark Brown wrote:
> Have you considered what it's going to mean for merges between branches?

I confess I had not. What is it going to mean? (That we might
inadvertently overwrite the hardcoded value as we merge changes
from a branch to trunk or between two branches?)

> Wouldn't letting the Makefile figure out the version from the pathname of one
> of the files be more reliable? If Subversion is like CVS and understands the
> $Source$ keyword you could even use it.

AFAICT from the manual, Subversion doesn't support the $Source$
keyword. It does have something similar, though: $HeadURL$ which
expands to "the full URL to the latest version of the file in the
repository:"
http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.advanced.props.special.keywords

If I understand correctly what you're suggesting, we could use it
in GNUMakefile.cfg to extract the name of the branch (or trunk)
and #define _RWSTD_VER in the generated config header. This would
(obviously) imply that we would need to remove the macro from the
library sources, and also that there would be no way to tell the
version of the library by simply grepping for the value of the
macro in the headers. One would either need to configure the
library first, or extract it from the name of $TOPDIR. For
maintenance branches like 4.2.x, we would also lose the ability
to #define _RWSTD_VER to the next version (e.g., 4.2.1, as it
is now). But we'd lose this ability if we were to adopt Andrew's
scheme as well.

I very much like the idea of storing the version in just one place
(i.e., the branch name) and automatically extracting it from there
but I'm not 100% sure I understand all the ramifications of this
solution to be completely sold on it yet.

What do others think? Does anyone see any significant downsides
to Mark's idea?

Martin

> 
> -- Mark
> 
> On Dec 13, 2007 2:24 PM, Martin Sebor <sebor@roguewave.com> wrote:
>> Andrew Black wrote:
>>> 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: 0xFFFFFFFF
>>> Trunk feature branch: 0xFFFFFFxx
>>> Major branch: 0xMMFF0000
>>> Maintenance branch: 0xMMmmFF00
>> Thanks, this is an interesting idea that I hadn't thought of.
>> At first I didn't think 0xFF made sense but I'm slowly starting
>> to warm up to it.
>>
>>> 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.
>> We'd have to find a way to avoid conflicts. I.e., How would one go
>> about finding the next available value of xx to grab for their new
>> feature branch? (It wouldn't be too hard to do today but if we had
>> as many feature branches as gcc, as unlikely as it is, it could be
>> a challenge.)
>>
>>> 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
>> Makes sense.
>>
>>> 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.
>> Same here.
>>
>>> Justification:
>>> 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.
>> I think I like this idea quite a bit, actually Using a fixed value
>> also makes it easy to test for it in release scripts and catch
>> releases where the macro isn't set correctly (because the value
>> would either be 0xFF or fail to match the version in the name of
>> the tag).
>>
>> Is everyone else happy with this scheme?
>>
>> Martin
>>