On 2/5/19 1:02 AM, Andres Freund wrote:
> Hi,
>
> On 2019-01-26 10:06:06 -0500, Tom Lane wrote:
>> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>>> The one "caveat" I will bring up is that once pushed and applied to the
>>> site, we would bring introduce a lot of 404s into the website.
>>
>> Hm. In principle we could probably insert some redirects, but
>> I doubt it's worth the trouble.
>>
>> If I haven't heard objections, I'll see about making this happen
>> during the first week of Feb (after the CF closes, but before
>> it's time to do the February releases' notes).
>
> Gah, I'd skipped this thread, because I was OK, if not happy, about the
> original modest proposal (trimming to supported versions). My fault.
>
> For the record: I think this is a terrible idea. Makes it much harder to
> figure out what changed when, and requires per-branch incantations to
> grep through the log. That's not to speak of the fact that now it's
> just about impossible to reference all releasenotes on the website in a
> useful manner now.
How frequently are you referencing release notes from older versions --
and I don't mean ones that are just deprecated, but things like 8.2? Or
even minor versions such as 8.2.5?
Is there a way to keep a balance on the code side: keep the source files
in but don't reference them to be built? That may not help with the
tarball size, but would certainly still help build times + lower
HTML/PDF output.
>
> For crying out loud, super prominent and often referenced URLs like
> https://www.postgresql.org/docs/devel/release-10.html
> are now broken, and soon URLs like
> https://www.postgresql.org/docs/current/release-10.html
> will be too.
We can set up some redirect rules for this in pgweb. We have a record of
what the latest version is, so we can intercept anything going to
`/current/release-(1?[0-9]+(\.[0-9]?` (untested regex) and point it to
the correct version.
The original thought process was to _not_ do that given the effort, but
if it's just for `/current/` it may not be so bad.
Jonathan