Hi,
On 2023-12-21 10:46:02 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2023-12-21 10:22:49 -0500, Tom Lane wrote:
> >> We could make it version-specific,
> >> https://www.postgresql.org/docs/17/installation.html
> >> and task src/tools/version_stamp.pl with updating it. But that's
> >> problematic for not-yet-released branches (there's no 17 today
> >> for example).
>
> > Perhaps we could make the website redirect 17 to /devel/ until 17 is branched
> > off?
>
> Hmm, maybe, but then there's a moving part in version-stamping that's not
> accessible to the average committer. On the other hand, it wouldn't
> be too awful if that redirect didn't get updated instantly after a
> branch. This is probably a point where we need advice from the web
> team about how they manage documentation branches on the site.
IIRC the relevant part of the website code has access to a table of
documentation versions, so the redirect could be implement based on not
knowing the version.
> >> Perhaps we can use /devel/ in the master branch
> >> and try to remember to replace that with a version number as soon
> >> as a release branch is forked off --- but does the docs website
> >> get populated as soon as the branch is made?
>
> > I think it runs a few times a day - breaking the link for a few hours wouldn't
> > be optimal, but also not the end of the world. But redirecting $vnext -> to
> > devel would probably be a more reliable approach.
>
> Let's go with "/devel/ in master and a number in release branches"
> for now, and tweak that if the web team wants to take on maintaining
> a redirect. I'll put together a concrete patch proposal in a little
> bit.
Cool.
Greetings,
Andres Freund