public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jonathan S. Katz <[email protected]>
To: Magnus Hagander <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: Release note trimming: another modest proposal
Date: Mon, 7 Jan 2019 21:18:29 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CABUevEzX3dq-uUeMR0mSnCj4B6TK3v4QuQKKsf6Oz+ZdyRHMZg@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<CABUevEzX3dq-uUeMR0mSnCj4B6TK3v4QuQKKsf6Oz+ZdyRHMZg@mail.gmail.com>

On 8/30/18 4:15 PM, Magnus Hagander wrote:
> On Fri, Aug 10, 2018 at 1:38 AM, Peter Eisentraut
> <[email protected]
> <mailto:[email protected]>> 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



Attachments:

  [application/pgp-signature] signature.asc (833B, 2-signature.asc)
  download

view thread (58+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Release note trimming: another modest proposal
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox