Stefan Seefeld wrote:
Beman Dawes wrote:
Joe Gottman wrote:
Beman Dawes wrote:
Boost 1.36.0 has been released and is available from SourceForge. See http://sourceforge.net/projects/boost/
This release include four new libraries:
I just downloaded the version 1.36 and the release history is completely blank.
Grrr...
One of my highest priority tasks for the next release is going to be to get a system in place that will automatically scan a release snapshot for the presence of certain files, and optionally verify size, date, and other properties.
From the various posts I have read related to the release process it sounds as if there is still a fair amount of manual work to be done in the process. Not only does this make life hard for release managers, but it is also quite error-prone, as this example demonstrates.
Yep.
Why can't the packaging process be automatized, making it fully reproducible?
That's what I've been trying to do, with some success, since last October. But the lengthy tool chains involved keep breaking, forcing manual intervention. Case in point, the doc build tool chain broke for this release, forcing a really messy workaround. Joel is trying to fix it now, but it is slow going since the test cases that fail for others works for him. That's been a battle for some time now with doc builds; configurations that work for one person don't work for another. It is also hard to automate process that have to switch back and forth between Windows and Linux. Again, the tool chain is unreliable.
Trying to increase the amount of tests run on the final package attacs the problem from the wrong end, IMO.
Probably, but I don't know how to attack some of the tool problems otherwise. For example, the problem of people changing the tool chain without realizing it has an impact on the automated release tools, and the problem of the automated release tools no longer producing some component (like docs) because of a tool change, and no one noticing. Thanks, --Beman --Beman