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. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
