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.
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.
Previously was using the quickbook file's pub_date, By using the date
the release script was run on, can release without updating the
quickbook file. So the release manger won't need to have quickbook
installed. At least in theory!
This code was added for transitioning from the old data format, now that
it is no longer in use, probably isn't needed any more. At some point
older version will stop working anyway as I'm not testing for full
backwards compatability. But I'll leave it in for a little while longer.
The problem is that if a beta had been released, then when the next
beta, or the final release was first added it would override the beta.
This would then set the status to unreleased. The whole release_status
mechanism is a bit messy and may need to be reconsidered.
So that the hah values remain the same as they are on master.
Probably more effort than was required to manually fix the hashes every
time they change, but I was getting a bit fed up of that. Although I
suspect some reason will still come up so that I'll have to manually fix
the hashes again.
Currently no way to update it (apart from manually, which is awkward),
but the plan is to do so automatically.
This messes up the hashes again. Probably best to resolve manually,
although it might be possible to emulate the old hashes.
- Both are now stored as strings.
- Unpublished articles have a null pub_date.
- last_modified is now always the last modified date,
before it was the pub_date once published.
