Re: Release note trimming: another modest proposal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
Cc: pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: Release note trimming: another modest proposal
Date: 2018-08-06 15:09:09
Message-ID: 18020.1533568149@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

"Jonathan S. Katz" <jkatz(at)postgresql(dot)org> writes:
>> On Aug 5, 2018, at 6:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> ... We could discuss ways
>> of making a complete release-note archive available somewhere,
>> if "go dig in the git repo" doesn't seem like an adequate answer
>> for that.

> Why not www.postgresql.org <http://www.postgresql.org/>? We could add it as a subnav to the
> documentation section and just have the entire archive there. We could
> then update the official docs to say “If you would like to reference release
> notes for earlier versions, please visit <URL>”

Yeah, that should certainly be part of it. The questions I have are

(1) Is it sufficient to have that info on the website? People who want
it locally can always fall back on searching the development git repo,
but it'd be less convenient perhaps.

(2) How would we maintain that exactly? It's not, for instance, possible
to build the release notes as a standalone document right now. (Bruce's
eagerness to provide xrefs for just about everything is the main stumbling
block, though there might be others.)

The process I'm vaguely imagining is that when a release branch is EOL'd,
before removing its release-NN.sgml file from the HEAD branch, we copy
that file into some archive somewhere and do a one-time edit to make it
buildable as part of a standalone release-notes document. Maybe the
"archive" contains a makefile and enough supporting stuff to build a
document that has just the obsolete release notes, and somewhere we have
a git repo for that. Then anybody who wants local access can clone that
repo (solving question 1), and we annually use it to build a new version
of the old-release-notes document to put on the website.

This seems like a nontrivial amount of work, but maybe we can automate it
to some extent.

regards, tom lane

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Jonathan S. Katz 2018-08-06 15:35:41 Re: Release note trimming: another modest proposal
Previous Message Jonathan S. Katz 2018-08-06 14:41:28 Re: Release note trimming: another modest proposal