Re: [Boost-docs] [ping]questions about boost documentation

Subject: Re: [Boost-docs] [ping]questions about boost documentation
From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-22 16:01:49

>> And
>> I don't like to use tools which are currently in development.
>
> Then don't use them. Use the ones in the releases, or plain HTML
> if you wish, or your own tools. Everything in the HEAD is under
> development, including libraries. I'm sure you already know that.

That's what I've been doing.  When I checked the RELEASE
branch from SVN that's where a saw all the things that provoked
my original email.  That is - directory structure and lack of html
but with pointers to html generated somewhere else.  This looked
all wrong to me as part of release.  I see now I failed to realise
a couple of things.

a) I didn't realise the that the release branch from SVN was
different from the release tarballs in that the tarballs have
the html generated.  Since I don't have the Tarball here and
I can't assume that its the same as the SVN release branch
I don't really know what the true situation is.  So sorry if
I've gotten wrong.

b) I thought I recalled email going back and forth regarding
the build of the documentation in relation to the release
of 1.34.  So I leapt to the conclusion that fixes and
development were going on on the 1.34 release candidate.
This was occuring with bjam and due to the long
gestation period of 1.34 so I may have painted too
much with a broad brush.

So it seems I've attributed some complaints to you guys
which probably be better directed at the boost release
process.  I'm sorry about this.

I've already made my best case regarding the release process
so I won't rehash it here.  Bottom line is that we have to work
on the assumption that there will be no changes in boost
development and release procedures.

One think you mightwant to look at while you're at it
is the boost web site section on "How to prepare
documentation"  Its waaaaaaaaaaaaaay out of date.
I used it as a basis for creation of the first version of the
serialization documentation and suffered because
it doesn't include any information as to how more
formal documentation should be prepared.

Robert Ramey