Re: Release note bloat is getting out of hand - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Release note bloat is getting out of hand
Date
Msg-id 16501.1422891837@sss.pgh.pa.us
Whole thread Raw
In response to Re: Release note bloat is getting out of hand  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Release note bloat is getting out of hand  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proposal : REINDEX xxx VERBOSE
Next
From: Robert Haas
Date:
Subject: Re: Release note bloat is getting out of hand