On Jul 24, 2008, at 4:28 PM, Gennadiy Rozental wrote:
Juergen Hunold
writes: 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
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?
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.
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.
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