[1.32 Release] Branch-for-release date
Hi All, With the new MPL in the main trunk and the updated MPL documentation coming later this week, we've finally come to the point when it's feasible to talk about the branch-for-release date. Given that there is still some work on regressions to be done, I'd like to aim for the end of the week, let's say Friday, September 17th. Does that sound OK to everybody? I'm assuming that at this point all library authors/maintainers are finished with the tasks they wanted to perform before the release, minor regression fixes aside. If not, please scream loudly! -- Aleksey Gurtovoy MetaCommunications Engineering
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:838645D2D4A9A64ABD56D8C001F07E0235341E@expressmail.office.meta... | Hi All, | | With the new MPL in the main trunk and the updated MPL documentation | coming later this week, we've finally come to the point when it's | feasible to talk about the branch-for-release date. | | Given that there is still some work on regressions to be done, | I'd like to aim for the end of the week, let's say Friday, | September 17th. Does that sound OK to everybody? sounds fine. br Thorsten
Aleksey Gurtovoy wrote:
Hi All,
With the new MPL in the main trunk and the updated MPL documentation coming later this week, we've finally come to the point when it's feasible to talk about the branch-for-release date.
Given that there is still some work on regressions to be done, I'd like to aim for the end of the week, let's say Friday, September 17th. Does that sound OK to everybody?
Nice to hear that! The assert test in MPL is failing on many compilers. Can you imagine what is the reason for that? (BTW ... another test with different results for VC 7.1 on different machines: one failing, one passing!). Stefan
Stefan Slapeta writes:
The assert test in MPL is failing on many compilers. Can you imagine what is the reason for that?
Fixed in the CVS already.
(BTW ... another test with different results for VC 7.1 on different machines: one failing, one passing!).
Hmm, this one _is_ a little wierd, since the regression was fixed only a few hours ago. [Digging into "RudbekAssociates.xml"...] Oh, it looks like the test hasn't been re-run since 2004-09-07, which explain why it's passing (everything was well back then; the breaking change to "boost/mpl/assert.hpp" was committed on "Wed Sep 8 17:47:27 2004 UTC"): <test-log library="mpl" test-name="assert" test-type="compile" test-program="libs/mpl/test/assert.cpp" target-directory="bin/boost/libs/mpl/test/assert.test/vc7.1/debug/threading-multi" toolset="vc7.1" show-run-output="false"> <compile result="succeed" timestamp="2004-09-07 04:56:26 UTC"> I don't have an explanation _why_ it hasn't been re-run, though. May be Victor can shed some light on this. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
I don't have an explanation _why_ it hasn't been re-run, though. May be Victor can shed some light on this.
Excerpt from comments.html:
Script that is run del results\*.log del \boost\lib\*boost* ... <<
Could it be that the deleting operations are not sufficient (esp. not deleting the XML files)? Stefan
All I can say is that the .bat file which runs the regression is available in the RudbekOld or RudbekAssociates links btw the reason for two sets of results is I'm bringing up a new machine and the results appeared to be different between my last run on the old system and the ones on the new system. Until we get this resolved it might be a good idea to publish both. As for WHY it hasn't run since Sep 7, I have no clue. I get the stuff from CVS, I run the tests (--incremental)... if bjam doesn't run all the tests it should, then we need to look there. I DO note that for some reason we're still running the teststreams test on VC8.0 (I don't know how to turn tests on/off, and I see my role as tester as someone who will run _exactly_ what's in the CVS. well, I did have to make some changes so that it would find my installation of vc8.0 and NOT try to build dot... Changes of the three files which show up as "M" follow C:\Projects\boost>cvs diff -w Jamfile.v2 Index: Jamfile.v2 =================================================================== RCS file: /cvsroot/boost/boost/Jamfile.v2,v retrieving revision 1.10 diff -w -r1.10 Jamfile.v2 26c26 < build-project libs/graph/build ; ---
# build-project libs/graph/build ;
C:\Projects\boost>cvs diff -w tools/build/v1/vc8.0-tools.jam Index: tools/build/v1/vc8.0-tools.jam =================================================================== RCS file: /cvsroot/boost/boost/tools/build/v1/vc8.0-tools.jam,v retrieving revision 1.1 diff -w -r1.1 vc8.0-tools.jam 9c9 < VC80_ROOT ?= $(ProgramFiles:J=" ")"\\Microsoft Visual Studio .NET Whidbey\\VC7" ; ---
VC80_ROOT ?= "g:\\program files\\Microsoft Visual Studio 8\\VC" ;
C:\Projects\boost>cvs diff -w tools/build/v2/user-config.jam Index: tools/build/v2/user-config.jam =================================================================== RCS file: /cvsroot/boost/boost/tools/build/v2/user-config.jam,v retrieving revision 1.13 diff -w -r1.13 user-config.jam 20c20 < # using gcc ; ---
using gcc ; 29c29,30 < # using msvc ;
using msvc : 7.1 ; using msvc : 8.0 ;
At Monday 2004-09-13 02:52, you wrote:
Stefan Slapeta writes:
The assert test in MPL is failing on many compilers. Can you imagine what is the reason for that?
Fixed in the CVS already.
(BTW ... another test with different results for VC 7.1 on different machines: one failing, one passing!).
Hmm, this one _is_ a little wierd, since the regression was fixed only a few hours ago. [Digging into "RudbekAssociates.xml"...] Oh, it looks like the test hasn't been re-run since 2004-09-07, which explain why it's passing (everything was well back then; the breaking change to "boost/mpl/assert.hpp" was committed on "Wed Sep 8 17:47:27 2004 UTC"):
<test-log library="mpl" test-name="assert" test-type="compile" test-program="libs/mpl/test/assert.cpp" target-directory="bin/boost/libs/mpl/test/assert.test/vc7.1/debug/threading-multi" toolset="vc7.1" show-run-output="false"> <compile result="succeed" timestamp="2004-09-07 04:56:26 UTC">
I don't have an explanation _why_ it hasn't been re-run, though. May be Victor can shed some light on this.
-- Aleksey Gurtovoy MetaCommunications Engineering
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On Sep 13, 2004, at 1:54 AM, Aleksey Gurtovoy wrote:
Given that there is still some work on regressions to be done, I'd like to aim for the end of the week, let's say Friday, September 17th. Does that sound OK to everybody?
I'm assuming that at this point all library authors/maintainers are finished with the tasks they wanted to perform before the release, minor regression fixes aside. If not, please scream loudly!
Sure, I think I can handle that. Doug
Aleksey Gurtovoy ha escrito:
Hi All,
With the new MPL in the main trunk and the updated MPL documentation coming later this week, we've finally come to the point when it's feasible to talk about the branch-for-release date.
Given that there is still some work on regressions to be done, I'd like to aim for the end of the week, let's say Friday, September 17th. Does that sound OK to everybody?
OK with me. My only problem is that I'll have limited or no access to the Internet during this weekend. Just in case some fixing to Boost.MultiIndex has to be done then (currently, everything's fixed up), how long will it take between branching and freezing the release candidate? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (3)
-
Aleksey Gurtovoy -
Doug Gregor -
Jeff Garland -
Joaquín Mª López Muñoz -
Stefan Slapeta -
Thorsten Ottosen -
Victor A. Wagner Jr.