On 8/30/18 4:15 PM, Magnus Hagander wrote:
> On Fri, Aug 10, 2018 at 1:38 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com
> <mailto: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.
So circling back on this, Peter's point makes a lot of sense.
If you want to see release notes for other major versions, there would
be URLs to the other major versions, but that would be far less costly
than keeping the actual release notes in each tarball.
So for example, let's take PostgreSQL 11:
https://www.postgresql.org/docs/11/release.html
We could do something like:
==snip==
- Release 11.1
Migration to Version 11.1
Changes
- Release 11.0
Migration to Version 11.1
Changes
Older Major Versions:
PostgreSQL 10 [URL to https://www.postgresql.org/docs/10/release.html]
PostgreSQL 9.6 [URL to https://www.postgresql.org/docs/9.6/release.html]
etc. etc.
== snip ==
That would both save significant space and hopefully solve the archiving
problem, as we would have the older docs available with all of their
respective versions.
The downside would be the PDFs, you would not have all the release notes
for, say PostgreSQL 10, in the PostgreSQL 11 PDFs. But I would argue
does that really matter? I could see that being helpful if you're
migrating between versions, but if you're using PostgreSQL 11, you're
using PostgreSQL 11 and the information for that version is the most
relevant.
It also seems like it'd make it easier to maintain the release notes
too, which would be another big win in addition to the build speedup.
Thoughts?
Jonathan
