Re: [Boost-users] run_test parameter not working (Boost Unit Test Framework)
Hi Gennadiy, Will this be released as a patch for 1.35 or just will be just released in the next version of boost? Will you please specify which file was fixed so that I can download myself and rebuild? thanks Marc ----- Original Message ---- From: Gennadiy Rozental <rogeeff@gmail.com> To: boost-users@lists.boost.org Sent: Thursday, July 17, 2008 11:18:13 PM Subject: Re: [Boost-users] run_test parameter not working (Boost Unit Test Framework) Marc Oliver Castañeda <floranteatlaura <at> yahoo.com> writes:
I believe this is fixed in svn. Therer was incorrect ifdef that disabled the functionality on most platforms. Gennadiy _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Marc Oliver Castañeda <floranteatlaura <at> yahoo.com> writes:
This hopefully is going to be part of next release (not sure if I need to do anything for this to happened). The file at fault is unit_test_main.ipp. Take trunk HEAD - it should be fine. Gennadiy
Hi Gennadiy ! On Wednesday 23 July 2008 19:34:31 Gennadiy Rozental wrote:
This hopefully is going to be part of next release (not sure if I need to do anything for this to happened).
Well, unfortunately not :-(( You had to to merge the libs to the release branch according to http://svn.boost.org/trac/boost/wiki/ReleaseSchedule and http://svn.boost.org/trac/boost/wiki/ImprovingPractices And at the former page we have: July 3, 2008: branches/release closes for routine minor changes and fixes. Still open for serious problem fixes. So, it's too late for 1.36.0 :-(( Well, I think you have to ask to release manager for permission to merge this one. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Juergen Hunold <juergen.hunold <at> ivembh.de> writes:
Not sure how it's an improvement. What is being used as base for release brunch? Why not pick up library trunk state automatically if it's passing all tests?
Well, I think you have to ask to release manager for permission to merge this one.
Not sure I'll have time for this double work. Anything that in a trunk can be (and should be) released. Gennadiy
Hi Gennadiy ! On Thursday 24 July 2008 22:28:32 Gennadiy Rozental wrote:
Please don't shoot the messenger :-))
Well, that is how most projects successfully work. But I don't comment on that decision any more... Thanks for adding the docs ! Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
On Jul 24, 2008, at 4:28 PM, Gennadiy Rozental wrote:
AFAIK, the trunk _is_ what is used to base the release branch, from some cut-off point the release manager decides, and informs the group about. Each library's maintainer should merge the readiest, but non- revolutionary, revision of his/her library around that cut-off point back into the release branch (if the cut-off point's revision is insufficient). If you been making either evolutionary changes or a non-bleeding-edge revolutionary change, you should merge in the last revision of those changes after the cut-off. If you just made a bleeding-edge change (i.e. you don't know all the consequences to all the platforms and/or fixed most of them), you should merge in the revision before the cut-off that is before the change. Just grabbing off the trunk is irresponsible. Even if we keep the trunk release-ready, which we are striving for, trunk-grabbing requires that we PROVE the release-readiness. That requires that we build & unit-test on every check-in (and reject failures). AFAIK, a Boost source tree requires hours to test, even if we run each platform vs. compiler/linker vs. configuration-parameters combination in parallel. This would back up our check-in times considerably, which is impractical. That's why we need a separate scratch space for our release trees, for proper clean-up and testing.
And that would be problematic for anyone who deliberately skipped the cut-off to add bleeding-edge changes (like me and Boost.Integer). We would have to warn the release manager to back out stuff, including any dependencies on the new stuff. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker <darylew <at> hotmail.com> writes:
Is it written somewhere? If it's true - I'll be fine.
Just grabbing off the trunk is irresponsible.
I meant at release cut-off point. Further fixed must be merged.
I meant Boost.Test specifically. Boost.Test is almost always release ready. The rest of your comment I do not follow. Gennadiy
participants (4)
-
Daryle Walker -
Gennadiy Rozental -
Juergen Hunold -
Marc Oliver Castañeda