As I only run it locally, this script doesn't need to run on PHP 5.3, but
travis checks all php scripts, and I don't think it's worth making an
exception.
There no support for release candidates yet, as we've never put them on
the site before. Will just treat it as the final release details to see
how well it works.
I think I'll use this in a cron job, so that updates to more public
pages can be checked before being released. Also won't have to deal with
automatically adding new files.
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.
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.
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.
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.
Prompted by:
http://stackstatus.net/post/147710624694/outage-postmortem-july-20-2016
Not really an issue here, as mostly processing our own files, so they
should be less problematic. The version number parsing code might have
an issue with really long URLs, but I don't think that's possible. But
fix it anyway.
Now get_modules works if there are no submodules, and stop throwing
exceptions for unusal submodule urls, since odeint has an external
documentation submodule.
