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
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
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 ?
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
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 09:35 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. > >Would you mind merging the latest toolsets into the trunk? Uh... I assume you mean merge the latest toolsets from the trunk into the RC_1_30_0 branch via the usual procedure for fixes to a branch? --Beman ___ 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
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 ?
> 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 ?
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 ?
- 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
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 ?
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 ?
> 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 ?
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 ?
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 ?
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 ?
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
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 ?
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 ?
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 ?
- 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
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 ?
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
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 ?
> 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 ?
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 ?
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
