Re: links to 12 release notes broken after branching

Hi,

On 2019-10-30 17:59:16 -0400, Jonathan S. Katz wrote:
> On 10/30/19 5:47 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2019-09-17 13:50:40 -0400, Jonathan S. Katz wrote:
> >> On 9/17/19 1:04 PM, Tom Lane wrote:
> >>> Andres Freund <andres(at)anarazel(dot)de> writes:
> >>>> Yes, but before the release being done we can't hand that out?
> >>
> >> You can always hand them out knowing that it is subject to change.
> >> Personally I view devel as "anything can change at a given moment".
> >
> > It still baffles me that that's supposed to be a reasonable approach.
>
> Why? "devel" is unstable by design.

I don't really buy this. Nor has it historically been true.

> Let's say we add a new feature, and the page is at
> /docs/devel/a/newfeature.html
>
> Some discussion ensues on the mailing list, and we decide that it's
> better to put the documentation in /docs/devel/b/newfeature.html
>
> Suddenly, all old links to /docs/devel/a/newfeature.html break.

> Could we add a redirect for it? Sure, but why would we account for every
> possible permutation when we know that devel in itself is unstable?

No, we shouldn't. I fail to see how a rare scenario about a renamed
feature is analogous to being unable to persistently link to the release
notes of an upcoming release.

Note that the feature renaming exists between different branches too,
and while it has created a complaint or two, it's pretty rare.

> > I
> > mean, for quite a few weeks that's the only link available. And we want
> > people to be able to look at the notes at that time. And expecting URLs
> > to stay halfway stable isn't a novel or absurd thing in any sort of way.
> >
> > I think the whole project of pruning the release notes was done hastily
> > and carelessly. At a much larger scope than necessarily apparent from
> > the mailing list discussions.
>
> What would you suggest we do?

I think the ship has largely sailed. Not do things like this again, I
guess.

> To kick off possible solutions, perhaps the policy is we keep the
> "/docs/devel/release-13.html" around in "master" after the
> REL_13_STABLE branch is created.

I don't understand why the obvious solution isn't to have
docs/devel/release-NN.html link to docs/NN/release-NN.html upon miss,
even while NN is not yet stable. That's a lot easier than unnecessarily
keeping files around, and works permanently.

You said before that it looks hairy to do so, but looking at
https://git.postgresql.org/gitweb/?p=pgweb.git;a=blob;f=pgweb/docs/views.py;h=1480903cf82229461b9e909c9829e8ad9aff87b7;hb=HEAD

it looks like all that's needed is allowing version specific redirects
after branching/betas/rc, but before the release? As far as I can tell
the current situation is that devel/release-NN.html links

1) work if NN hasn't yet branched off

2) stop working once NN has has branched, and release-NN.sgml is removed
from master, because
83 is_released = Version.objects.filter(tree=release_version, testing=0).exists() if version == "devel" else True
returns false, due to the testing = 0 check, which in turn means:
86 if is_released and release_version != ver:
will not trigger a redirect yet. Which means we'll get a 404.

3) starts working again once NN is "fully" released
because now is_released is true

isn't all that's needed to rename is_released to exists_as_branch, and
remove the testing=0 condition?

> We keep that around until the time that 13.0 comes out, and then it is
> removed to make way for release-14.html
>
> Does that work? What is the overhead of maintaining that in core?

Definitely non-zero and ongoing due to minor release notes. Or
confusing, bdecause it'll be outdated.

Greetings,

Andres Freund