Beman Dawes wrote:
Robert Ramey wrote:
This would work well with other testing and release procedures. That is, testing and release would use the last released tool version, NOT the one being refined in the trunk. This would be in line with what I hope will be the future of boost in that libraries are tested against last release and rolled into the release ready version as they prove that they are ready for prime time.
Yes, although the problems we've been having aren't so much with new tools as with existing tools that break unexpectedly (and/or worse yet, silently).
Also, the breaking change may be in a tool that Booster's don't maintain, such as Doxygen or xsltproc.
The same could be said for libraries. Actually, to me, the most important part of the testing process is detecting when something that I depend upon changes. I complain about this all the time - but even if no one introduced breaking changes, there is always new stuff - new compilers, new versions of stl, new os variations, corrections in libraries which catch previously undetected errors of my own. My real point is that there is no reason that any tools that are used by boost should be treated any differently than any libraries used by boost.
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost