Re: [boost] [1.47.0] Beta 1 Release candidate files available

Subject: Re: [boost] [1.47.0] Beta 1 Release candidate files available
From: Robert Ramey (ramey_at_[hidden])
Date: 2011-06-20 18:12:03

Daniel James wrote:
> On 20 June 2011 20:46, Barend Gehrels <barend_at_[hidden]> 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