So that it will pick up new release notes. It also means that the state
will be updated for other pages. They won't be rebuilt, but I feel that
the state should only be updated when they are actually going to be
built. Maybe add an option to `update_qbk_file` to only update
development pages. Or perhaps only scan for new files that aren't in
pages yet.
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.
It doesn't include all the data the is currently stored, there's some
code that attempts to work round that, but it generates incomplete pages
because some of the data is missing. So better just to clear the cache.
It's a bit awkward, but to generate a page needed to update
BoostPages_Page, which wasn't always appropriate. So now generate pages
just using the data from the quickbook source, combined with the state
data.
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.
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.
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.
The php and python versions of fragment_to_string act differently for
xml nodes that aren't fragments. I really should have called
fragment_to_string something different, or at least only used it for
actual fragments.
