[boost] Re: plans for a bugfix release ?
Aleksey Gurtovoy [EMAIL PROTECTED] writes: David Abrahams wrote: Thanks for all the testing; the release looks pretty darned great! Just to make sure it's understood - although expected, all the green failures are still failures. Not that we can do much about them, of course. From a user POV, a darned great release would be the one for which http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/user_summary_page.html would reveal a clear green field, without any details links to check. Yep. http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_result_page.html Only one red box (intel-7.1-stlport lexical_cast)! ... which means a regression from 1.30.0 ;). Yes, I know. To be fair, quite a few failures have been fixed (dark green cells) Yes. http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html Still, it would be nice if we didn't release until _all_ regressions are fixed. I agree, but nobody seemed to be paying attention to that problem. I wonder what our maintenance wizard is up to...? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Misha Bergal [EMAIL PROTECTED] writes: David Abrahams wrote: It looks like you need to build your vc6 stlport debug library also; that would account for the failure in the testing library tests. Done. Thanks for all the testing; the release looks pretty darned great! http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_result_page.html Only one red box (intel-7.1-stlport lexical_cast)! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
David Abrahams wrote: Thanks for all the testing; the release looks pretty darned great! Just to make sure it's understood - although expected, all the green failures are still failures. Not that we can do much about them, of course. From a user POV, a darned great release would be the one for which http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/user_summary_page.html would reveal a clear green field, without any details links to check. http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_result_page.html Only one red box (intel-7.1-stlport lexical_cast)! ... which means a regression from 1.30.0 ;). To be fair, quite a few failures have been fixed (dark green cells) - http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html Still, it would be nice if we didn't release until _all_ regressions are fixed. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Misha Bergal [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] writes: I am slightly concerned about the number of unexpected failures with intel7.1-stlport. Is there a configuration problem? Yes, there is. The main trunks intel-win32-tools.jam,1.28 enables wchar_t for our configuration but RC_1_30_0 intel-win32-tools.jam,1.23 doesn't. Our STL installation is compiled with wchar_t support. I will setup another copy compiled without it. Done. The results for intel7.1-stlport are definetely better now, there is just one regression in lexical_cast_test - I will take a look at it. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
David Abrahams [EMAIL PROTECTED] writes: Could you possibly do another regression run? There have been quite a few little changes since the last one. Sure, actually we are running the regressions on RC_1_30_0 continuously, with the interruptions for configuration changes and power outages (they happen here). We get sources from main SF CVS, one run takes about 6 hours (we do clean rebuilds) - so the results on the web site should be really up-to-date. Please ignore the results for Comeau if there are still there - it has been enabled by mistake. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Misha Bergal [EMAIL PROTECTED] writes: Misha Bergal [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] writes: I am slightly concerned about the number of unexpected failures with intel7.1-stlport. Is there a configuration problem? Yes, there is. The main trunks intel-win32-tools.jam,1.28 enables wchar_t for our configuration but RC_1_30_0 intel-win32-tools.jam,1.23 doesn't. Our STL installation is compiled with wchar_t support. I will setup another copy compiled without it. Done. The results for intel7.1-stlport are definetely better now, there is just one regression in lexical_cast_test - I will take a look at it. It looks like you need to build your vc6 stlport debug library also; that would account for the failure in the testing library tests. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: plans for a bugfix release ?
David Abrahams wrote: It looks like you need to build your vc6 stlport debug library also; that would account for the failure in the testing library tests. Done. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Misha Bergal [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thanks. The hyperlinks to test failure logs don't ever scroll to the appropriate section of the output on IE6. Fixed The compiler_status changes from main trunk need to be integrated back to RC_1_30_0 . If I don't hear from somebody about it, I will just apply patch locally. Done Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
David Abrahams [EMAIL PROTECTED] writes: I am slightly concerned about the number of unexpected failures with intel7.1-stlport. Is there a configuration problem? Yes, there is. The main trunks intel-win32-tools.jam,1.28 enables wchar_t for our configuration but RC_1_30_0 intel-win32-tools.jam,1.23 doesn't. Our STL installation is compiled with wchar_t support. I will setup another copy compiled without it. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Misha Bergal [EMAIL PROTECTED] writes: Misha Bergal [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thanks. The hyperlinks to test failure logs don't ever scroll to the appropriate section of the output on IE6. Fixed The compiler_status changes from main trunk need to be integrated back to RC_1_30_0 . If I don't hear from somebody about it, I will just apply patch locally. Done Could you possibly do another regression run? There have been quite a few little changes since the last one. Thanks, Misha! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Misha Bergal [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Bronek Kozicki [EMAIL PROTECTED] writes: I another round of testing would be great. According to ... http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_result_page.html tests on the branch haven't been run in some time. Thanks. The hyperlinks to test failure logs don't ever scroll to the appropriate section of the output on IE6. I am slightly concerned about the number of unexpected failures with intel7.1-stlport. Is there a configuration problem? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thanks. The hyperlinks to test failure logs don't ever scroll to the appropriate section of the output on IE6. The compiler_status changes from main trunk need to be integrated back to RC_1_30_0 . If I don't hear from somebody about it, I will just apply patch locally. Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Bronek Kozicki [EMAIL PROTECTED] writes: David Abrahams wrote on July 16th: Beman Dawes [EMAIL PROTECTED] writes: [...] How will we prevent a 1.30.1 release from delaying a 1.31.0 release? By releasing one week from now? Hello what is current status for boost release 1.30.1 ? Do you need volunteers to run tests before releasing it, or do some other work ? I another round of testing would be great. According to http://boost.sourceforge.net/regression-logs/ and http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_result_page.html tests on the branch haven't been run in some time. Or it's already released, and boost.org site is being updated right now ? I plan to take the next step this evening, if test results look good by then. Thanks for asking, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
David Abrahams wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: Any reason you cannot use http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html? None, in particular. This table is a little weird though: http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_result_page.html#mpl It is. It's due to a bug in 'process_jam_log.cpp', which confuses the tests with the same names from different libraries (MPL and Preprocessor, in this case). We didn't have time to fix it yet. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Aleksey Gurtovoy wrote: Martin Wille writes: I'll run the tests for Linux and upload them as Linux-rc-1.30.0. They should be available in a few hours. Can you arrange the html so that it shows regressions from the 1.30.0 release results? Hmm, I'd have to find out how I would do that. Is there already some support for showing diffs between two versions of the test result tables? For the new regression report format, yes. For instance, here's the CVS main trunk report against the 1.30.0 tarball - http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html If you are interested in producing these, we will provide you with the scripts. You'd need an XSLT processor and Python, but beside that it's as simple as running a Python script after the regression run. Hmm, why don't you add those scripts to the tools/regression section of the CVS? If there isn't such a thing I would try to implement something that reads two tables and marks the differences. That would take a day or two, I guess. Please, don't! If you have the prerequisits installed, setting up a step to produce the new-format reports should take about 15 minutes, and they are way much more informative. I've got Python and OpenJade installed. So, I'm ready to run your scripts. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: plans for a bugfix release ?
From: Misha Bergal Sent: Wednesday, July 16, 2003 9:45 PM To: '[EMAIL PROTECTED]' Subject: RE: [boost] Re: plans for a bugfix release ? Sounds fine to me. The only issue remaining is how we can get the testing infrastructure to start testing RC_1_30_0. I would like to see the results of a round of testing on the current CVS state of that branch before we commit to a 1.30.1 release, just to make sure it's viable. Here are the results we have: 1.30.0 tarball: http://tinyurl.com/h6cx CVS main trunk (relative to 1.30.0 tarball): http://tinyurl.com/h6d0 CVS RC_1_30_0 branch (relative to 1.30.0 tarball): http://tinyurl.com/h6d7 (will be available in 9 hours) CVS RC_1_30_0 branch results (relative to 1.30.0 tarball) are available now. Notes: * A number of our toolsets are different from standard boost ones. They have been patched 1) to allow the extending of them (as in the case of borland) 2) to fix the configuration problems we think boost jam files had (as in the case of intel-7.1-stlport). We plan to make the description of changes available from the status web pages, but haven't done it yet * our Intel toolsets are installed to work in vc6.0 compatibility mode * We have patched STL 4.5.3 Intel compiler make file * We are open to suggestions regarding adding new toolsets to our tests. Obviously it is not possible to test all configurations - so some selection criteria needs to be set up. Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Misha Bergal wrote: Here are the results we have: 1.30.0 tarball: http://tinyurl.com/h6cx CVS main trunk (relative to 1.30.0 tarball): http://tinyurl.com/h6d0 CVS RC_1_30_0 branch (relative to 1.30.0 tarball): http://tinyurl.com/h6d7 (will be available in 9 hours) CVS RC_1_30_0 branch results (relative to 1.30.0 tarball) are available now. The developers summary page summarizes things quite nicely (light green OK cell means there has been no regression): http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 11:50 AM 7/16/2003, David Abrahams wrote: ... The only issue remaining is how we can get the testing infrastructure to start testing RC_1_30_0. I would like to see the results of a round of testing on the current CVS state of that branch before we commit to a 1.30.1 release, just to make sure it's viable. See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/ I found I had to update the .../tools/build sub-tree to the current main trunk in order to get the latest toolsets. Other than that, the tests were run on the RC_1_30_0 branch. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Beman Dawes [EMAIL PROTECTED] writes: See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/ I found I had to update the .../tools/build sub-tree to the current main trunk in order to get the latest toolsets. Other than that, the tests were run on the RC_1_30_0 branch. Would you mind merging the latest toolsets into the trunk? Thanks, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Beman Dawes [EMAIL PROTECTED] writes: See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/ I found I had to update the .../tools/build sub-tree to the current main trunk in order to get the latest toolsets. Other than that, the tests were run on the RC_1_30_0 branch. How can I tell if there were regressions? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
David Abrahams [EMAIL PROTECTED] writes: Beman Dawes [EMAIL PROTECTED] writes: See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/ I found I had to update the .../tools/build sub-tree to the current main trunk in order to get the latest toolsets. Other than that, the tests were run on the RC_1_30_0 branch. Would you mind merging the latest toolsets into the trunk? Sorry, of course I meant into the RC_1_30_0 branch. -Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 09:36 AM 7/17/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/ I found I had to update the .../tools/build sub-tree to the current main trunk in order to get the latest toolsets. Other than that, the tests were run on the RC_1_30_0 branch. How can I tell if there were regressions? Regressions compared to the current main trunk or to the 1.30.0 release? One simple way to spot regressions compared to the current main trunk is to look at VC++ 7.1. Except for Boost.Signals, it is currently passing 100% of all tests. Thus any failures are regressions compared to the current state. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 11:02 AM 7/17/2003, David Abrahams wrote: David Abrahams [EMAIL PROTECTED] writes: Beman Dawes [EMAIL PROTECTED] writes: See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/ I found I had to update the .../tools/build sub-tree to the current main trunk in order to get the latest toolsets. Other than that, the tests were run on the RC_1_30_0 branch. Would you mind merging the latest toolsets into the trunk? Sorry, of course I meant into the RC_1_30_0 branch. Will do. Please ignore my previous post asking you if that was what you meant. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Beman Dawes [EMAIL PROTECTED] writes: At 09:36 AM 7/17/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: See win32-1_30_1 on http://boost.sourceforge.net/regression-logs/ I found I had to update the .../tools/build sub-tree to the current main trunk in order to get the latest toolsets. Other than that, the tests were run on the RC_1_30_0 branch. How can I tell if there were regressions? Regressions compared to the current main trunk or to the 1.30.0 release? 1.30.0 One simple way to spot regressions compared to the current main trunk is to look at VC++ 7.1. That only tells me about one compiler, and the main trunk (which I don't care about). Except for Boost.Signals, it is currently passing 100% of all tests. Thus any failures are regressions compared to the current state. We're not trying to get things to be as good as the current CVS; we just want better than 1.30.0. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Hi,
On Tue, 15 Jul 2003 23:38:12 +0200, Daniel Frey wrote:
I think it's too late, let's go for a 1.31.0. I think that we'll hear
about problems with the 1.31.0 really soon after release and probably a
1.31.1 can follow shortly after.
Agreed.
At our company we use a slightly different approach. We have two development
streams, which we call 'Master' and 'Release'. At some time, when we are
releasing a version from our main development branch ('Master'), we just make
a copy of the current 'Master' state and check it into a different source
control database ('Release'). Bug fixes will be added into the 'Master' and
into the 'Release' branch. However, new functionality and interface changes
are only added into the 'Master'. Of course it is a little bit more work to
add the bug fixes into two seperate RCS. But this way, we are able to bring
bug fix releases to our clients whenever there is a demand for it. Additionally,
it then is possible to make complete structural changes to the 'Master' without
concernig about the 'Release'.
Regards, Johannes
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Beman Dawes wrote: Seems like we are very close to being ready to do a 1.31.0 release. One new library has been added since 1.30.0, at least two libraries have had interface upgrades, and a large number of bugs have been fixed in numerous libraries. How about 1 or maybe more betas of 1.31.0 (like we had for 1.30.0) so that hopefully some problems can be found before the final release? Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
David Abrahams wrote: [Beman Dawes] Hum... You must be seeing some way of getting a 1.30.1 release out that eludes me. What would go into 1.30.1? Exactly what's on the end of the RC_1_30_0 branch plus whatever additional small fixes were deemed important and can be applied in a day or two; release to happen in a week. Spirit has also just released its next version, should this also be integrated into any boost 1.30.1? [I will ask same question on Spirit list, and direct discussion back here] Only *critical* fixes to the 1.30.0 release. What about updated compiler configs? For instance, Borland released a compiler update pretty much the same week that Boost 1.30 went out, so several version checks fail. Any other compilers release a point upgrade that can be easily integrated? By releasing one week from now? Agressive dealine will certainly focus us on 'needs' not 'wants' g -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Alisdair Meredith [EMAIL PROTECTED] writes: David Abrahams wrote: [Beman Dawes] Hum... You must be seeing some way of getting a 1.30.1 release out that eludes me. What would go into 1.30.1? Exactly what's on the end of the RC_1_30_0 branch plus whatever additional small fixes were deemed important and can be applied in a day or two; release to happen in a week. Spirit has also just released its next version, should this also be integrated into any boost 1.30.1? No. Those are not *critical* fixes. [I will ask same question on Spirit list, and direct discussion back here] Only *critical* fixes to the 1.30.0 release. What about updated compiler configs? For instance, Borland released a compiler update pretty much the same week that Boost 1.30 went out, so several version checks fail. Any other compilers release a point upgrade that can be easily integrated? By releasing one week from now? Agressive dealine will certainly focus us on 'needs' not 'wants' g That would be the idea. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Johannes Brunen [EMAIL PROTECTED] writes:
At our company we use a slightly different approach. We have two development
streams, which we call 'Master' and 'Release'. At some time, when we are
releasing a version from our main development branch ('Master'), we just make
a copy of the current 'Master' state and check it into a different source
control database ('Release').
Bug fixes will be added into the 'Master' and into the 'Release'
branch. However, new functionality and interface changes are only
added into the 'Master'.
Presumably that's exactly what we're doing with branches.
Of course it is a little bit more work to add the bug fixes into two
seperate RCS.
So why not simply branch instead? It's better than making a whole
new copy.
But this way, we are able to bring bug fix releases to
our clients whenever there is a demand for it. Additionally, it then
is possible to make complete structural changes to the 'Master'
without concernig about the 'Release'.
There's no reason to use a separate CVS for this. I guess if you're
using RCS you might not be able to do it; I don't recall whether it
supports branching directly.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
From: Alisdair Meredith [EMAIL PROTECTED] Only *critical* fixes to the 1.30.0 release. What about updated compiler configs? For instance, Borland released a compiler update pretty much the same week that Boost 1.30 went out, so several version checks fail. Any other compilers release a point upgrade that can be easily integrated? Yes. g++ 3.3 is not recornized by 1.30.0. This is mostly harmeless, except for a annoying warning on using almost every boost header. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 08:36 PM 7/15/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: ... Hum... You must be seeing some way of getting a 1.30.1 release out that eludes me. What would go into 1.30.1? Exactly what's on the end of the RC_1_30_0 branch plus whatever additional small fixes were deemed important and can be applied in a day or two; release to happen in a week. Ah! That is much more doable. Who will act as release manager? I guess I'd have to reluctantly volunteer, now that I've suggested it. Sounds like you just talked your way into a new job:-) So a schedule might look something like the following? -- 1.30.1 - Selected bug fixes only (details up to release manager). Schedule: a week or two from now -- 1.31.0 - New library, breaking interface changes, many fixes. Schedule: TBA, but work is basically already well underway. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 06:17 AM 7/16/2003, Alisdair Meredith wrote: David Abrahams wrote: Only *critical* fixes to the 1.30.0 release. What about updated compiler configs? For instance, Borland released a compiler update pretty much the same week that Boost 1.30 went out, so several version checks fail. Any other compilers release a point upgrade that can be easily integrated? VC++ 7.1 required two or three workarounds IIRC. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Alisdair Meredith wrote: Spirit has also just released its next version, should this also be integrated into any boost 1.30.1? Yes, Spirit 1.6.1 should be incorporated into a Boost 1.30.1 release (if we actually decide to release 1.30.1). [I will ask same question on Spirit list, and direct discussion back here] Alisdair, I think most (if not all) Spirit developers have also subscribed to this mailing list. Only *critical* fixes to the 1.30.0 release. Spirit 1.6.1 only fixes bugs of Spirit 1.6.0, no features have been added. Boost.Spirit users would benefit from a Boost 1.30.1 release. However, Boost 1.30 users can replace Boost.Spirit with the contents of Spirit 1.6.1. So, from this point of view, a 1.30.1 release is not necessary. Personally, I think 1.30.1 would be a good thing to have. My impression is that many people try to access the Boost CVS in order to pick some fixes that were made right after the release of Boost 1.30. Given the lousy quality of public CVS access we're experiencing at the moment, users will likely appreciate a 1.30.1 release. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Beman Dawes [EMAIL PROTECTED] writes: At 08:36 PM 7/15/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: ... Hum... You must be seeing some way of getting a 1.30.1 release out that eludes me. What would go into 1.30.1? Exactly what's on the end of the RC_1_30_0 branch plus whatever additional small fixes were deemed important and can be applied in a day or two; release to happen in a week. Ah! That is much more doable. Who will act as release manager? I guess I'd have to reluctantly volunteer, now that I've suggested it. Sounds like you just talked your way into a new job:-) So a schedule might look something like the following? -- 1.30.1 - Selected bug fixes only (details up to release manager). Schedule: a week or two from now I would be more hard-*ssed about it. A week. -- 1.31.0 - New library, breaking interface changes, many fixes. Schedule: TBA, but work is basically already well underway. Sounds fine to me. The only issue remaining is how we can get the testing infrastructure to start testing RC_1_30_0. I would like to see the results of a round of testing on the current CVS state of that branch before we commit to a 1.30.1 release, just to make sure it's viable. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Martin Wille [EMAIL PROTECTED] writes: F David Abrahams wrote: Martin Wille writes: Hi, you wrote: Sounds fine to me. The only issue remaining is how we can get the testing infrastructure to start testing RC_1_30_0. I would like to see the results of a round of testing on the current CVS state of that branch before we commit to a 1.30.1 release, just to make sure it's viable. I'll run the tests for Linux and upload them as Linux-rc-1.30.0. They should be available in a few hours. Can you arrange the html so that it shows regressions from the 1.30.0 release results? Hmm, I'd have to find out how I would do that. Is there already some support for showing diffs between two versions of the test result tables? Yes. Beman? If there isn't such a thing I would try to implement something that reads two tables and marks the differences. That would take a day or two, I guess. In the meantime I'll publish tests for the 1.30.0 release and the for release candidate unmodified. I think the results are useful even without having the differences marked. Regards, m PS: Linux-rc-1_30_0 is available now. I'll run the tests for 1.30.0 release tonight. They will be available in about 9 hours. Thanks! -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 11:50 AM 7/16/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: So a schedule might look something like the following? -- 1.30.1 - Selected bug fixes only (details up to release manager). Schedule: a week or two from now I would be more hard-*ssed about it. A week. OK. I'll try to get a Win32 regression test run the 1_30_0 branch ASAP. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 04:54 PM 7/16/2003, David Abrahams wrote: Martin Wille [EMAIL PROTECTED] writes: Hmm, I'd have to find out how I would do that. Is there already some support for showing diffs between two versions of the test result tables? Yes. Beman? I have a hack that I use to produce http://boost.sourceforge.net/regression-logs/cs-win32-diff.html It proves the concept, so to speak, but is way too unreliable. Fails when new compilers are added, for example. What is really needed is to add a history element to the test_log.xml files. That would be far more reliable. Let me think about it overnight. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: plans for a bugfix release ?
From: David Abrahams [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 10:51 AM Sounds fine to me. The only issue remaining is how we can get the testing infrastructure to start testing RC_1_30_0. I would like to see the results of a round of testing on the current CVS state of that branch before we commit to a 1.30.1 release, just to make sure it's viable. Here are the results we have: 1.30.0 tarball: http://tinyurl.com/h6cx CVS main trunk (relative to 1.30.0 tarball): http://tinyurl.com/h6d0 CVS RC_1_30_0 branch (relative to 1.30.0 tarball): http://tinyurl.com/h6d7 (will be available in 9 hours) Our plan is to have the up-to-date CVS RC_1_30_0 branch and CVS main trunk results every day. Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Martin Wille writes: I'll run the tests for Linux and upload them as Linux-rc-1.30.0. They should be available in a few hours. Can you arrange the html so that it shows regressions from the 1.30.0 release results? Hmm, I'd have to find out how I would do that. Is there already some support for showing diffs between two versions of the test result tables? For the new regression report format, yes. For instance, here's the CVS main trunk report against the 1.30.0 tarball - http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html If you are interested in producing these, we will provide you with the scripts. You'd need an XSLT processor and Python, but beside that it's as simple as running a Python script after the regression run. If there isn't such a thing I would try to implement something that reads two tables and marks the differences. That would take a day or two, I guess. Please, don't! If you have the prerequisits installed, setting up a step to produce the new-format reports should take about 15 minutes, and they are way much more informative. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Beman Dawes wrote: At 04:54 PM 7/16/2003, David Abrahams wrote: Martin Wille [EMAIL PROTECTED] writes: Hmm, I'd have to find out how I would do that. Is there already some support for showing diffs between two versions of the test result tables? Yes. Beman? I have a hack that I use to produce http://boost.sourceforge.net/regression-logs/cs-win32-diff.html It proves the concept, so to speak, but is way too unreliable. Fails when new compilers are added, for example. What is really needed is to add a history element to the test_log.xml files. That would be far more reliable. Let me think about it overnight. The way we do it in the new reports is to extract the failures from the original regression run and pass them as expected failures to the input of the scripts producing the today's reports. The scripts merge these into extended results XML, and then produce the HTML reports basing on that. Works perfectly. All XML processing is done through XSLT, but it's very worth it - the stlysheets which do the extracting and merging are barely 100 lines long. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
- Original Message - From: Aleksey Gurtovoy [EMAIL PROTECTED] Beman Dawes wrote: What is really needed is to add a history element to the test_log.xml files. That would be far more reliable. Let me think about it overnight. The way we do it in the new reports is to extract the failures from the original regression run and pass them as expected failures to the input of the scripts producing the today's reports. The scripts merge these into extended results XML, and then produce the HTML reports basing on that. Works perfectly. All XML processing is done through XSLT, but it's very worth it - the stlysheets which do the extracting and merging are barely 100 lines long. Aleksey I don't have the time now, but if it's feasible for you I would absolutely _love_ if we could integrate this with BoostBook in the future. If I had my way, everything would run through the documentation system so that everything would be documented (see, e.g., the testsuite documentation and generation for Function) and in sync. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Dominique Devriese [EMAIL PROTECTED] writes: David Abrahams writes: Hi, I'm the main developer of Kig [1]. I have just committed the code for python scripting to the CVS repository Using Boost.Python? Cool! Yups, I was going to post something separately about including it on the projects using boost.python page if you want, but well, erm.. if you want, feel free to include it on that page.. :) ( There's no released version with the scripting yet, but I consider the code itself to be pretty stable.. ) If you need more information, feel free to ask. Please give me a blurb for the page, preferably in HTML, so I don't have to work too hard. Are there any plans to release a fixed version of Boost.Python any time soon No specific plans, no. and what is the policy on Boost.Python releases in general ? In general, they are released when all of Boost is ready. I think it would be a *really* good idea for Boost to do at least one minor version release shortly after any major version release. Now that we have a reasonable testing strategy it should be relatively easy. Boost 1.30.0 went out with several bugs IIRC. Until we get our act together, I would suggest you supply people with a Boost patch. Use BOOST_DEDUCED_TYPENAME instead of typename so you don't break VC6. Sorry, A fixed release would be great indeed. In the mean time, I'm going to provide the patch as you suggest, although it's far from a perfect solution of course.. I know. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Dominique Devriese [EMAIL PROTECTED] writes: In general, they are released when all of Boost is ready. I think it would be a *really* good idea for Boost to do at least one minor version release shortly after any major version release. Now that we have a reasonable testing strategy it should be relatively easy. Boost 1.30.0 went out with several bugs IIRC. Until we get our act together, I would suggest you supply people with a Boost patch. Use BOOST_DEDUCED_TYPENAME instead of typename so you don't break VC6. Sorry, A fixed release would be great indeed. In the mean time, I'm going to provide the patch as you suggest, although it's far from a perfect solution of course.. What does everybody think about doing a 1.30.1 release RSN? I don't think there's much to it, unless people have been checking things into the 1.30 branch unintentionally. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 10:26 AM 7/15/2003, David Abrahams wrote: Dominique Devriese [EMAIL PROTECTED] writes: In general, they are released when all of Boost is ready. I think it would be a *really* good idea for Boost to do at least one minor version release shortly after any major version release. Now that we have a reasonable testing strategy it should be relatively easy. Boost 1.30.0 went out with several bugs IIRC. Until we get our act together, I would suggest you supply people with a Boost patch. Use BOOST_DEDUCED_TYPENAME instead of typename so you don't break VC6. Sorry, A fixed release would be great indeed. In the mean time, I'm going to provide the patch as you suggest, although it's far from a perfect solution of course.. What does everybody think about doing a 1.30.1 release RSN? What would be the advantage of doing a 1.30.1 release rather than a 1.31.0 release? Seems like we are very close to being ready to do a 1.31.0 release. One new library has been added since 1.30.0, at least two libraries have had interface upgrades, and a large number of bugs have been fixed in numerous libraries. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Beman Dawes [EMAIL PROTECTED] writes: At 10:26 AM 7/15/2003, David Abrahams wrote: Dominique Devriese [EMAIL PROTECTED] writes: In general, they are released when all of Boost is ready. I think it would be a *really* good idea for Boost to do at least one minor version release shortly after any major version release. Now that we have a reasonable testing strategy it should be relatively easy. Boost 1.30.0 went out with several bugs IIRC. Until we get our act together, I would suggest you supply people with a Boost patch. Use BOOST_DEDUCED_TYPENAME instead of typename so you don't break VC6. Sorry, A fixed release would be great indeed. In the mean time, I'm going to provide the patch as you suggest, although it's far from a perfect solution of course.. What does everybody think about doing a 1.30.1 release RSN? What would be the advantage of doing a 1.30.1 release rather than a 1.31.0 release? When we released 1.30.0, despite extensive pre-release testing, it went out with several prominent showstopper bugs. Don't you think we'll make the same mistake for 1.31.0? Also, AFAICT 1.30.1 can go out much, much sooner. Seems like we are very close to being ready to do a 1.31.0 release. One new library has been added since 1.30.0, at least two libraries have had interface upgrades, and a large number of bugs have been fixed in numerous libraries. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: When we released 1.30.0, despite extensive pre-release testing, it went out with several prominent showstopper bugs. Don't you think we'll make the same mistake for 1.31.0? Also, AFAICT 1.30.1 can go out much, much sooner. I agree with Dave here. To me there is another good reason for doing minor releases more frequently. Neither the next major release nor the CVS state is likely to help most of the people who use Boost in their projects. I guess that there are a lot of projects out there that cannot allow for an interface change in one of the core libs every couple of month. So they really need bugfix only releases if showstopper bugs are found in the last release. Just my 2c Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: plans for a bugfix release ?
David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: When we released 1.30.0, despite extensive pre-release testing, it went out with several prominent showstopper bugs. Don't you think we'll make the same mistake for 1.31.0? Also, AFAICT 1.30.1 can go out much, much sooner. I agree with Dave here. To me there is another good reason for doing minor releases more frequently. Neither the next major release nor the CVS state is likely to help most of the people who use Boost in their projects. I agree that we should publish patch releases more frequently. But the question here what is the criteria whether the release should be considered patch or next one. In my projects I choose the following strategy: if release does not affect the interface, so that I could simply substitute one shared library with patched one - this is patch release. In other case it's next release. It may be a little different with boost, cause most of the staff in the headers. But the idea should be IMO similar. I guess that there are a lot of projects out there that cannot allow for an interface change in one of the core libs every couple of month. So they really need bugfix only releases if showstopper bugs are found in the last release. We should've publish patch release right after we discovered them. IMO at this point, with all those iterator adaptor changes I would rather made new release. Just my 2c Thomas Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
On Tue, 15 Jul 2003 19:19:08 +0200, Thomas Witt wrote David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: When we released 1.30.0, despite extensive pre-release testing, it went out with several prominent showstopper bugs. Don't you think we'll make the same mistake for 1.31.0? Also, AFAICT 1.30.1 can go out much, much sooner. I agree with Dave here. To me there is another good reason for doing minor releases more frequently. Neither the next major release nor the CVS state is likely to help most of the people who use Boost in their projects. I guess that there are a lot of projects out there that cannot allow for an interface change in one of the core libs every couple of month. So they really need bugfix only releases if showstopper bugs are found in the last release. I agree with with the idea of a minor release to fix critical nasty bugs. My list from 1.30.0 would be: 1) Lexical cast fix that went in shortly after 1.30 was released 2) Missing change html file in date-time linked from main page (fixed on web, but not install package) 3) The change you'all have been discussing. By selecting only a small set of critical changes the lead up to the release should be very quick. Adding new libraries, major interface changes etc mean it will take weeks before we are really ready for a release. Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
At 11:50 AM 7/15/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 10:26 AM 7/15/2003, David Abrahams wrote: Dominique Devriese [EMAIL PROTECTED] writes: In general, they are released when all of Boost is ready. I think it would be a *really* good idea for Boost to do at least one minor version release shortly after any major version release. Now that we have a reasonable testing strategy it should be relatively easy. Boost 1.30.0 went out with several bugs IIRC. Until we get our act together, I would suggest you supply people with a Boost patch. Use BOOST_DEDUCED_TYPENAME instead of typename so you don't break VC6. Sorry, A fixed release would be great indeed. In the mean time, I'm going to provide the patch as you suggest, although it's far from a perfect solution of course.. What does everybody think about doing a 1.30.1 release RSN? What would be the advantage of doing a 1.30.1 release rather than a 1.31.0 release? When we released 1.30.0, despite extensive pre-release testing, it went out with several prominent showstopper bugs. Don't you think we'll make the same mistake for 1.31.0? No, of course not. There is only one new library ready for 1.31.0. We've essentially been working on 1.31.0 for several months. A huge amount of effort has gone into finding and fixing bugs. The iterator adaptor changes have temporarily obscured the progress, but it is there nonetheless. Also, AFAICT 1.30.1 can go out much, much sooner. Hum... You must be seeing some way of getting a 1.30.1 release out that eludes me. What would go into 1.30.1? There have probably been hundreds of changes to CVS since the 1.30.0 tag. How would we distinguish what should or should not be merged into a 1.30.1 branch? Who will make the decisions? Who will do the testing? Who will act as release manager? How will we prevent a 1.30.1 release from delaying a 1.31.0 release? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
On Tue, 15 Jul 2003 16:26:43 +0200, David Abrahams wrote: What does everybody think about doing a 1.30.1 release RSN? I think it's too late, let's go for a 1.31.0. I think that we'll hear about problems with the 1.31.0 really soon after release and probably a 1.31.1 can follow shortly after. For 1.30.0, we IMHO missed the opportunity do to a 1.30.1 without lots of pain/work. As Beman already said there is too much in CVS to backport it to a 1.30.1. The question is, whether we learn from it for a 1.31.1 :) My 2 cents... Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
Hello.. Typically what i do for releases is something along the line of this. prject - x,yy,zz x - major architecture changes. yy - minor changes. (uneven for development). zz - no interface changes. bug fixes. I try to release the zz often (for stable). Everytime there is a critical fix or a few bug fixes that are causing people problems. For the unstable versions i try to release as soon as there are some cool features in there that need testing. If things go really well on an unstable release and the features that we want are in then i consider a new stable version. Rember the release early and often. The longer its being developed in cvs the more bugs that are going to be around during a stable release. I personnaly don't like the major release scheduals for anything other then major releases. Anything that is going to take 6 months to a year should be a major release. Minors are like once a month.. And patchs as soon as there is enough problems to require one. Ben - Original Message - From: Rozental, Gennadiy [EMAIL PROTECTED] To: 'Boost mailing list' [EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 3:09 PM Subject: RE: [boost] Re: plans for a bugfix release ? David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: When we released 1.30.0, despite extensive pre-release testing, it went out with several prominent showstopper bugs. Don't you think we'll make the same mistake for 1.31.0? Also, AFAICT 1.30.1 can go out much, much sooner. I agree with Dave here. To me there is another good reason for doing minor releases more frequently. Neither the next major release nor the CVS state is likely to help most of the people who use Boost in their projects. I agree that we should publish patch releases more frequently. But the question here what is the criteria whether the release should be considered patch or next one. In my projects I choose the following strategy: if release does not affect the interface, so that I could simply substitute one shared library with patched one - this is patch release. In other case it's next release. It may be a little different with boost, cause most of the staff in the headers. But the idea should be IMO similar. I guess that there are a lot of projects out there that cannot allow for an interface change in one of the core libs every couple of month. So they really need bugfix only releases if showstopper bugs are found in the last release. We should've publish patch release right after we discovered them. IMO at this point, with all those iterator adaptor changes I would rather made new release. Just my 2c Thomas Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
- Original Message - From: Daniel Frey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 15, 2003 11:38 PM Subject: [boost] Re: plans for a bugfix release ? On Tue, 15 Jul 2003 16:26:43 +0200, David Abrahams wrote: What does everybody think about doing a 1.30.1 release RSN? I think it's too late, let's go for a 1.31.0. Agreed. I think that we'll hear about problems with the 1.31.0 really soon after release and probably a 1.31.1 can follow shortly after. And 1.31.x, yes. For 1.30.0, we IMHO missed the opportunity do to a 1.30.1 without lots of pain/work. As Beman already said there is too much in CVS to backport it to a 1.30.1. The question is, whether we learn from it for a 1.31.1 :) Personally I'd have to learn to manage different CVS branches accordingly. I believe, we'd need some kind of approximate schedule, too. Oh, and someone should volunteer for the job of the release manager. My 2 cents... Already 4 cents, Joerg ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Beman Dawes [EMAIL PROTECTED] writes: At 11:50 AM 7/15/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 10:26 AM 7/15/2003, David Abrahams wrote: Dominique Devriese [EMAIL PROTECTED] writes: In general, they are released when all of Boost is ready. I think it would be a *really* good idea for Boost to do at least one minor version release shortly after any major version release. Now that we have a reasonable testing strategy it should be relatively easy. Boost 1.30.0 went out with several bugs IIRC. Until we get our act together, I would suggest you supply people with a Boost patch. Use BOOST_DEDUCED_TYPENAME instead of typename so you don't break VC6. Sorry, A fixed release would be great indeed. In the mean time, I'm going to provide the patch as you suggest, although it's far from a perfect solution of course.. What does everybody think about doing a 1.30.1 release RSN? What would be the advantage of doing a 1.30.1 release rather than a 1.31.0 release? When we released 1.30.0, despite extensive pre-release testing, it went out with several prominent showstopper bugs. Don't you think we'll make the same mistake for 1.31.0? No, of course not. There is only one new library ready for 1.31.0. We've essentially been working on 1.31.0 for several months. A huge amount of effort has gone into finding and fixing bugs. The iterator adaptor changes have temporarily obscured the progress, but it is there nonetheless. Also, AFAICT 1.30.1 can go out much, much sooner. Hum... You must be seeing some way of getting a 1.30.1 release out that eludes me. What would go into 1.30.1? Exactly what's on the end of the RC_1_30_0 branch plus whatever additional small fixes were deemed important and can be applied in a day or two; release to happen in a week. There have probably been hundreds of changes to CVS since the 1.30.0 tag. How would we distinguish what should or should not be merged into a 1.30.1 branch? Only *critical* fixes to the 1.30.0 release. Who will make the decisions? Individual library developers. Who will do the testing? Whoever does testing for any release? Who will act as release manager? I guess I'd have to reluctantly volunteer, now that I've suggested it. How will we prevent a 1.30.1 release from delaying a 1.31.0 release? By releasing one week from now? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Daniel Frey [EMAIL PROTECTED] writes: On Tue, 15 Jul 2003 16:26:43 +0200, David Abrahams wrote: What does everybody think about doing a 1.30.1 release RSN? I think it's too late, let's go for a 1.31.0. I think that we'll hear about problems with the 1.31.0 really soon after release and probably a 1.31.1 can follow shortly after. For 1.30.0, we IMHO missed the opportunity do to a 1.30.1 without lots of pain/work. As Beman already said there is too much in CVS to backport it to a 1.30.1. The question is, whether we learn from it for a 1.31.1 :) I wouldn't dream of backporting everything we've done since 1.30.0. That would be pointless. There are just a few errors which prevent major portions of 1.30.0 from compiling. I backported all the important post-1.30.0 fixes immediately after hearing about them, but I'm not sure everyone else did. Note that 1.31.0 is going to be a code-breaking release for anyone who uses iterator adaptors, so it might be important for them to get a working 1.30.1. But anyway, I don't care that much. A .1 release is more work, and I'm all for avoiding work. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
The following message is a courtesy copy of an article that has been posted to gmane.comp.python.c++ as well. Dominique Devriese [EMAIL PROTECTED] writes: Hi, I'm the main developer of Kig [1]. I have just committed the code for python scripting to the CVS repository Using Boost.Python? Cool! but I'm receiving bug reports from people not able to compile the new code because of the small typename problem that was fixed in Boost.Python some time ago [2] ( the fix is in CVS, right ? ). Yes. Are there any plans to release a fixed version of Boost.Python any time soon No specific plans, no. and what is the policy on Boost.Python releases in general ? In general, they are released when all of Boost is ready. I think it would be a *really* good idea for Boost to do at least one minor version release shortly after any major version release. Now that we have a reasonable testing strategy it should be relatively easy. Boost 1.30.0 went out with several bugs IIRC. thanks domi Footnotes: [1] http://edu.kde.org/kig [2] http://mail.python.org/pipermail/c++-sig/2003-May/003889.html and http://mail.python.org/pipermail/c++-sig/2003-May/003896.html Until we get our act together, I would suggest you supply people with a Boost patch. Use BOOST_DEDUCED_TYPENAME instead of typename so you don't break VC6. Sorry, -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
