Re: Release note bloat is getting out of hand

Magnus Hagander <magnus@hagander.net> writes:
> Yeah, the PDF size is definitely someting to consider in this context. And
> the limits.

> But if we can find some good way to "archive" or preserve them *outside the
> main docs* that should solve this problem, no? We could keep them in SGML
> even, but make sure they are not actually included in the build? Would
> still be useful for developers there...

> Or if we could find a way to do like Josh says - archive them separately
> and publish a separate download. We could even keep it in a separate git
> repo if we have to, with a "migrate" job to run on a major release?

Yeah, seems like this and Josh's request could both be addressed fine
with a separate document.

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?
        regards, tom lane