Re: Release note trimming: another modest proposal
Magnus Hagander <magnus@hagander.net>
From: Magnus Hagander <magnus@hagander.net>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-docs@lists.postgresql.org
Date: 2018-08-30T20:15:19Z
Lists: pgsql-docs
On Fri, Aug 10, 2018 at 1:38 AM, Peter Eisentraut < peter.eisentraut@2ndquadrant.com> wrote: > On 06/08/2018 00:57, Tom Lane wrote: > > Anyway, I'd like to propose a compromise position that I don't think > > has been discussed before: let's drop release notes for branches > > that were already EOL when a given branch was released. So for > > example, 9.3 and before would go away from v12, due out next year. > > Working backwards, we'd drop 9.1 and before from v10, giving the 15% > > savings in page count that I showed above. A quick measurement says > > that would also trim the size of the v10 tarball by about 4%, which > > is not a lot maybe but it's noticeable across a lot of downloads. > > Why not go further and just ship the release notes of the current major > version. If you want to look at the release notes of version 11, read > the documentation for version 11. Who reads the documentation of > version 12 to get the release notes of version 11? > +1 for that. At least if we get a generic release notes index up on the website, easy to find. That might also make the process of manually merging release notes back and forth in the release process easier, I assume? -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Commits
-
Doc: in each release branch, keep only that branch's own release notes.
- ed64db588a67 9.5.16 landed
- bb428cb11722 9.4.21 landed
- 60b1d6c2a736 9.6.12 landed
- 2b24271153ec 10.7 landed
- 0d13dd371b64 11.2 landed
- 527b5ed1ad46 12.0 landed