Re: [HACKERS] Proposal for changes to recovery.conf API

On Sun, Dec 18, 2016 at 12:41:01PM +0100, Magnus Hagander wrote:
>     No, they become uninteresting to anyone who has passed Postgres 10.  I
>     would argue they are still required to be around even after we stop
>     supporting Postgres 9.6 because we know everyone will not upgrade off of
>     supported releases once we stop supporting them.  This means we can
>     effectively never remove the information.
>
>
> This is true, but I think it's also safe to say that it's acceptable that if
> you are upgrading from an unsupported version you need to read more than one
> set of documentation -- one set to get to a supported one, and one get on from
> there.

How do you propose they find that other documentation set if upgrading
from 9.6 to version 16?  Do we put the old docs somewhere on our web
site?  Do we have them download a tarball and unpack it?  How do we
handle old translated doc versions?  I realize the wiki isn't
translated, but if we have translators translate it, we should keep it
available.

>     Right now if you migrate from Postgres 8.0 to Postgres 9.6, all the
>     information you need is in the 9.6 documentation.  If you were to remove
>     migration details from 8.4 to 9.0 they would have to look at the 9.0
>     docs to get a full picture of how to migrate.
>
>
> In fairness, all the information you need is definitely not in the
> documentation. You have all the release notes, that is true. But for a lot of
> people and in the case of a lot of features, that is not at all enough
> information. But it's true in the sense that it's just as much information as

Uh, what exactly is this additional information you are talking about?
Blogs?  Are you saying we have information about upgrades we have
captured but discard?

>     Again, I am fine putting this as a subsection of the release notes, but
>     let's not pretend it is some extra section we can remove in five years.
>
>
> Depends on what we decide to do about it, but sure, it could certainly turn
> into another section that we keep around (whether as part of the release notes,
> or as a separate "upgrade steps" section or something).

I suggest whatever we do, we place the information in a permanent
location that isn't moved or removed.