Travis Vitek wrote:
Martin Sebor wrote:
Farid Zaripov wrote:
-----Original Message-----
From: Martin Sebor (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 29, 2008 7:31 PM
To: Farid Zaripov
Subject: [jira] Updated: (STDCXX-711) [MSVC] 0.fnmatch fails
Since {{rw_fnmatch()}} is a new interface it _probably_
shouldn't go in 4.2.1 but rather in 4.3. Changed Fix
Version/s accordingly.
I say _probably_ because the function is part of the test
driver and not the library itself, and I'm not sure we have a
policy or have even discussed whether the compatibility
policy (http://stdcxx.apache.org/releases.html) applies to
other stdcxx components besides just the library.
It's a good question to discuss.
I think that the rwtest library, the examples and tests (in other
words:
the anything except the C++ library) are not intended for using in
customer projects. Elsewere, for example, the adding of the new
regression
tests could be considered as the forward incompatible change.
True, they're not intended to be used in user projects. But adding
a function to the driver means that tests compiled against it won't
link with the previous version of the driver. This will become an
issue if/when the driver becomes a shared library. Then we won't
be able to drop them in to a BUILDDIR of the previous release and
run them to check binary compatibility of the library as we did
in 4.2.0.
Martin
Why would someone want to be able to drop the rwtest library into the
BUILDDIR of a previous version? If you are testing binary compatibility of
the stdcxx library, you would want to drop the stdcxx library in there.
The user is expecting to use the stdcxx includes and the library with their
application. That is where the binary compatibility contract must be
honored. The user should not using the test driver in this way, so there
should be no compatibility contract.
Good point. I guess I was thinking about it backwards, in terms
of dropping the new tests into another buildspace, rather than
doing that with libstdcxx.so. But that's probably not something
we will want or need to do.
The other use case that I suspect was in the back of mind, even
though I didn't articulate it, was recompiling new tests with
the old driver and library. I know I needed to do it in the past
to reproduce issues in the old version of the library that were
fixed in the new version. I think this was either between 4.1.2
and 4.1.3, or between 4.1.3 and 4.2, after we added a whole bunch
of new tests that didn't exist in the previous release. I'm, not
sure how much of an issue this will be going forward (probably
less and less, as our test suite becomes more complete), but it's
something worth considering.
Martin
