I wrote:
> BTW, while we're thinking about this --- I remembered that as things
> stand, we've broken my historical practice of putting up first-draft
> minor release notes for people to look at if they choose. Those will
> now be in the newest back branch, which we don't have an automatic
> build-and-post pipeline for, AFAIK. Now, maybe the people who would
> review those notes are all comfortable with looking at the git
> commitdiff anyway. But somebody who preferred to wait for the next
> guaibasaurus run and then look at the website is now out of luck.
> Would it be possible to drive this aggregation off the git copies
> of release-NN.sgml (from appropriate branches) instead of the last
> released versions? Or set up something equivalent to the devel
> notes pipeline for back branches?
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. It'd have a simple(?) Makefile with
the only build product being the aggregate release notes as
HTML (maybe PDF too). The constituent files would be copies
of the release-NN.sgml files from the master code repo. There'd
be no particular need for multiple branches in this repo, it'd
just be latest data all the time.
The main drawback of this approach is the need to copy the
release-NN.sgml files from the master code repo. But since
we'd only touch it four or five times a year, that doesn't
seem like unacceptable overhead to me. The benefits are:
* It's not so hard to cope with the fact that the various
branches don't all use the same docs toolchain. We'd just
agree that the release notes repo uses the current toolchain,
and when transferring over old release notes, they'd have to
be edited as necessary to make them build.
* The web site could be set up to build-and-publish from this
repo automatically, more or less like the devel docs are published
from the master code repo automatically. That'd fix the problem
I worry about above: drafts could be published by shoving them into
the release note repo ahead of official release.
(Contrariwise, if we had say a security-related update we did
*not* want to be visible immediately, we'd just delay transferring
that to the release note repo.)
I'd be willing to do most of the legwork in populating this repo,
if someone else were to handle the website plumbing.
regards, tom lane