Re: Proposal for changes to recovery.conf API

On Sun, Dec 18, 2016 at 1:57 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> 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.
>

We have all the old documentation up on the website, yes. So far it goes
back to 6.3. There is no reason to stop that.

The wiki is not a good location for documentation that needs to be around
for a long time.

For translated docs, that's really up to each translation team, since we
don't have any central repository for it. We do have that for the
translation of the code, but not docs.

> > 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?
>

Exactly the type of information that Simon is suggested that he writes this
time.

The *how* to migrate.

And no, we don't have this information "officially" today. Some of it is in
blogs, most of it is in the mailinglist archives. The proposal here is,
AIUI, to formalize that so we have it in the formal documentation in the
future.

> > 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.
>
>
+1. Absolutely. That's a very important point.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/