Re: Release note trimming: another modest proposal - Mailing list pgsql-docs

From Tom Lane
Subject Re: Release note trimming: another modest proposal
Date
Msg-id 12370.1549389732@sss.pgh.pa.us
Whole thread Raw
In response to Re: Release note trimming: another modest proposal  ("Jonathan S. Katz" <jkatz@postgresql.org>)
List pgsql-docs
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> On 2/5/19 11:37 AM, Tom Lane wrote:
>> After further thought about that, I'm liking the idea that was
>> discussed upthread of setting up a separate git repo for the
>> aggregate release notes.

> The contrary point I will make is handling this via a different method.
> I believe one of the things Magnus objected to in the original patch
> upthread (or in a private conversation) was that we were double-storing
> the release note data in the patch I proposed.

Yeah, the $64 question is whether that is a feature or a bug.

A big thing that I like about how matters stand right now is that there's
one source of truth about what are the release notes for release X.Y[.Z].
Previously, it was never real clear about whether HEAD or that release
branch had precedence, and the possibility of different markup
requirements in the two branches didn't make that better.  Plus, as
Andres points out, *only* the release branch really provided correct
pointers in any links to the rest of the docs.

If we could avoid the separate git repo, and instead do some
redirection magic to sew together the existing pages
https://www.postgresql.org/docs/X/release-Y-Z.html
for only pages with X = Y, that would be cool probably.

            regards, tom lane


pgsql-docs by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: Release note trimming: another modest proposal
Next
From: Jürgen Purtz
Date:
Subject: Re: First SVG graphic