Moved the logic for handling beta pages into convert_quickbook_pages as
it didn't make much sense in load_quickbook_page. Also simplified a bit
as there should always be a cached entry for a beta page. Perhaps should
store the beta pages in a separate file?
To fix the bug where the development release notes didn't have all the
appropriate data.
I might not do this, I feel like it might be better to create a new
'section'.
So that they don't overwrite the beta release notes. This means that
there's no way to update the beta release notes, but I guess that can be
done manually.
I'm going to create a new page for 'in progress' release notes, and only
write the release notes pages for actual release (including beta
releases). That way the beta release notes can be left in place while
the release notes are updated for the next beta/full release. Changes to
the release notes after the final release will be updated.
Can still go wrong if the submodule name contains an equal sign or a
period, or the value contains a newline. But since this isn't dealing
with arbitrary data, that seems unlikely.
boost_archive.php:
For mime types, the current list seems fine, and a full list doesn't
seem feasable.
boost_filter_text.php:
For supporting other character sets, could possibly use
mb_detect_encoding to guess the file's encoding, but it's not currently
installed on the server, and I think guesses are probably no better than
just assuming everything is UTF-8. The alternative would be some
mechanism to specify a file's (path's?) encoding, but I'm sure that can
be done if the need arises.
boost_library.php:
If it turns out that a better exception is needed, then it will be
handled then, so I'm not concerned with that TODO note.
boost_pages.php:
Sourceforge is redirecting downloads to the right place, so I'll not
bother with '/download' at the end. It's probably better if the download
URLs have the right filename.
boost_simple_template.php:
I don't think the simple template class really needs to support tricky
edge cases, so I'll just leave that alone.
doc/libraries.php:
I don't think anyone's desperate to see the library list for ancient
versions. If they are, they can get the it in json format using:
http://www.boost.org/doc/libraries.json.php?version=1.11.1
site-tools/git-prep-beta.sh:
Coming back to this, I think the answer is no. A change on master is
only really made when it has been pushed to remote, if it's only local
then it might get rebased.
This script doesn't actually get much use now that there are long
standing unmerged changes in beta, but it used to work well for me.
site-tools/update-doc-list.php:
Other TODO note was to make the script a little more automatic when run
against a local git tree, but I don't think that's a use case to support
in general. The tree might not be fully synced, or might be checked out
from a tag, which would be harder to check.
It used to just grab anything that looked like a version number from a
string. Now the whole string must be a version number. Left the library
list in a little bit of a mess, but will clean that up next.
Remove a little duplication and makes it easier to see how the class is
actually used. Would normally be stored in a separate file, but I didn't
really want to create one.
So that a release can have a version number before it goes into beta.
Note: needed to run update-doc-list for this to work, as the serialised
documentation list includes version numbers.
I was thinking about resolving this by removing the release data for
bjam, but instead support different release names. Even though this is
currently just for one special case, might be useful in the future.
Main change is that 'unversioned.qbk' now has null release_data. Will
result in a change to the qbk_hash, but I'll manually handle that. This
means that its no longer a 'release' but still want it to appear on
history page.
Was updating it every time an item was updated, this was unnecessarily
slow. Typically, only a very small number of items are updated per run,
so it shouldn't make much of a difference, but a lot faster if many
items are updated.
Pretty large development merge. Including:
- More robust PHP error handling.
- Automatically update release data from various sources. Manually
updating a json file was too error prone.
- Normalize hashes of release notes, so that they won't need to be
manually updated so often.
- Small improvements to quickbook page data.
- Cache html generated from quickbook - so no need to reparse when
changing release data. Much of the site can now be rebuilt without
installing quickbook, although changes in quickbook won't be included.
- Scripts in site-tools have are more consistent at the command line,
and all support '--help' (although some have very little information).
- Automatically update more of the site for new releases.
