On 2/4/20 3:34 AM, Magnus Hagander wrote:
> On Mon, Feb 3, 2020 at 9:59 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>> So, if there was something done to redirect people from specific
>> deprecated documentation pages historically, it was before my time. Most
>> of the redirects have been as general purposes ones (e.g. /docs/12), the
>> rules we put in for getting rid of "static", and the release notes,
>> which still receives some negative feedback towards it for different
>> reasons (though I think overall the effort was well-received). Anyway,
>> if we had a redirect in place, I'd want us to do it well.
>
> We have something close to it in commit
> 496416ceda9c1015d9e7a6ef4b4fb18dae8a8d4e. But that doesn't actually
> generate redirects when requests are coming in from the outside -- it
> just makes sure our *internal* links can survive the rename of a file
> between branches.
Ah cool, didn't realize we had this feature :)
> So it may not be exactly what's being looked for here, but it might be
> a starting point. Probably the same underlying mapping table could be
> used, but I haven't investigated that closely enough to say if it's
> doable at this point, just that it's a starting point.
Yeah. It could be as simple as having a flag on it to say it should
redirect if the old file (presumably "file2" in the model) is hit. I'm
saying this without diving into the mechanics of the code.
> Using this feature to handle the rename of a file *between* major
> versions, thus leaving the changes in master, should be safe (as long
> as we add an entry to that table in pgweb).
>
> As for back branches, I think we have to say that it's too close to
> the minor release to safely have something done in pgweb before then.
This part I agree on, but let's sync offline to see if there is
something within reason, with a preference to *not* rush if we're
worried about breaking something right before release.
Jonathan