Hi, On 2023-12-21 10:46:02 -0500, Tom Lane wrote: > Andres Freund <and...@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