Daniel James wrote:
On 20 June 2011 20:46, Barend Gehrels <barend@xs4all.nl> wrote:
I found one remarkable thing, don't know if it is a problem. The file boost-release-docs.7z contains docs for some (but not all) libraries in the html folder. There is also a libs folder containing only the docs of Boost.Geometry. What is the reason for that?
That's the documentation that I build and upload. Beman's release scripts downloads it and adds it to the release, so that he doesn't have to build the documentation.
I think this is the source of a very annoying (for me) problem. I maintain a local copy of the boost release from SVN. This lets me test my own changes against the next release so any problem that occurs is almost for certain my own. I'm almost guarenteed that when my locao changes migrate through the trunk to the release branch there will be no problems. Also, since the release branch updates far less frequently, it's much easier for me to keep in sync. So far so good. But there is one big pain - and that's the boost documentation. It seems it's not part of the release tree but rather built separately and merged into the release. This means that I don't really have the latest documentation available as I do the code. That is, they are not in sync. I would like to be developing other projects against the "next release" but the lack of the latest documentation is unhelpful. Couldn't we do the following? Fix up the bjam scripts so that directories look like: root/libs/mylib/doc/html/... And every day do an incremental rebuild of the html directories. This shouldn't take a lot of time since release doesn't change that often and when it does, only that documentation which is changed has to be re-generated. Now I can just use my release branch mirror for development, etc - just like I owuld use for the release. I would effectively have the "point release" sitting on my desk and I could update from the release branch when it was convenient to me. The release managers's job would then be almost trivial: a) make announcements b) freeze the release branch for a week or two before release c) give wavers to those who can't make the schedule. d) tag and build the release for shipment. e) re-open the release branch for commits.
From my stand point I wouldn't have to get the latest release and rebuild it just to get updated documentation.
If everyone did it this way, the "next" release would be continuously tested in addition to the official testers. Robert Ramey