On 02/02/2015 07:54 AM, Robert Haas wrote:
>> I could live with keeping the ancient-branch release note SGML files
>> > around in HEAD --- I'd hoped to reduce the size of tarballs a bit, but the
>> > savings by that measure would only be a few percent (at present anyway).
>> > What's more important is to get them out of the main documentation build.
>> > So how about cutting the main doc build down to last-five-branches,
>> > and adding a non-default make target that produces a separate document
>> > consisting of (only) the complete release note history?
> The last 5 branches only takes us back to 9.0, which isn't very far.
> I would want to have at least the 8.x branches in the SGML build, and
> maybe the 7.x branches as well. I would be happy to drop anything
> pre-7.x from the docs build and just let the people who care look at
> the SGML. You seem to be assuming that nobody spends much time
> looking at the release notes for older branches, but that is certainly
> false in my own case.
I was suggesting having a separate "historical release notes" tarball,
actually. If that's in SGML, and can be built using our doc tools, we
haven't lost anything and we've reduced the size of the distribution
tarball.
One of the things I've been tinkering with for a while is a better
searchable version of the release notes. The problem I keep running
into is that it's very difficult to write an error-free importer from
the present SGML file; there's just too much variation in how certain
things are recorded, and SGML just isn't a database import format.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
