From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)postgresql(dot)org, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Subject: | Re: ci: Build standalone INSTALL file |
Date: | 2023-12-21 15:30:05 |
Message-ID: | 20231221153005.ueqksfne7ajgp4c4@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-12-21 10:22:49 -0500, Tom Lane wrote:
> I think the only real question is what URL to point at exactly. We can't
> simply say
>
> https://www.postgresql.org/docs/current/installation.html
>
> because that will be wrong for any version more than one major
> release back.
Right.
> 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?
> 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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2023-12-21 15:32:51 | Re: index prefetching |
Previous Message | Andres Freund | 2023-12-21 15:26:56 | Re: Track in pg_replication_slots the reason why slots conflict? |