Re: Release note trimming: another modest proposal

On 2019-02-05 08:50:16 -0500, Jonathan S. Katz wrote:
> 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?

Not never, but acceptably rare. That's why I didn't protest loudly when
Tom proposed cutting those; I like having them in tree, but Tom cares
about not having too many, so that seemed like a reasonable
compromise. But then this thread got a lot more extreme.


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

Well, the still supported stuff actually makes a ton of sense to have in
a release. E.g. looking up minor release notes of the old release when
doing a pg_upgrade makes sense.


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

I think it definitely should also be on /devel/, that's what's out there
on blog posts and such.  I am flummoxed that we're just giving up google
juice by willy nilly returning 404 for stuff that's more widely linked
than the average page. It's not like we are that good placed in searches
(although that's primarily related to other things).

Greetings,

Andres Freund