Re: Release note trimming: another modest proposal

On 5 August 2018 at 23:57, Tom Lane wrote: > Anyway, I'd like to propose a compromise position that I don't think > has been discussed before: let's drop release notes for branches > that were already EOL when a given branch was released. WFM. +1 Regards, Dean

Re: Release note trimming: another modest proposal

> On Aug 5, 2018, at 6:57 PM, Tom Lane wrote: > > We've been around on this before, I know, but I got annoyed about it > again while waiting around for test builds of the back-branch > documentation. I think that we need some policy about maintaining > back-branch release notes that's not "keep

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: >> On Aug 5, 2018, at 6:57 PM, Tom Lane wrote: >> ... We could discuss ways >> of making a complete release-note archive available somewhere, >> if "go dig in the git repo" doesn't seem like an adequate answer >> for that. > Why not www.postgresql.org

Re: Release note trimming: another modest proposal

> On Aug 6, 2018, at 11:09 AM, Tom Lane wrote: > > "Jonathan S. Katz" writes: >>> On Aug 5, 2018, at 6:57 PM, Tom Lane wrote: >>> ... We could discuss ways >>> of making a complete release-note archive available somewhere, >>> if "go dig in the git repo" doesn't seem like an adequate answer >

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: > Though thinking on this further, we’d probably want to maintain the URLs > that have been generated through the years so they don’t all 404 at once. > That would require having the appropriate URL rules written out either in > pgweb itself or at the web server level.

Re: Release note trimming: another modest proposal

On 2018-Aug-06, Tom Lane wrote: > OTOH, if we can easily set up a generic redirect rule like "if > https://www.postgresql.org/docs/*/static/release-*.html > doesn't exist, then redirect to > https://www.postgresql.org/docs/old-release-notes/static/release-*.html"; > it might be worth doing. Yeah

Re: Release note trimming: another modest proposal

> On Aug 6, 2018, at 11:47 AM, Tom Lane wrote: > > "Jonathan S. Katz" writes: >> Though thinking on this further, we’d probably want to maintain the URLs >> that have been generated through the years so they don’t all 404 at once. >> That would require having the appropriate URL rules written o

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: > FWIW I’m thinking of something like: > `/docs/release-notes/release-X-Y(-Z)?.html` > and have them all live there. Of course the docs themselves would still > have their copy of the release notes, but we could at least have a single > repository of all the releases,

Re: Release note trimming: another modest proposal

> On Aug 6, 2018, at 12:55 PM, Tom Lane wrote: > > "Jonathan S. Katz" writes: >> FWIW I’m thinking of something like: > >> `/docs/release-notes/release-X-Y(-Z)?.html` > >> and have them all live there. Of course the docs themselves would still >> have their copy of the release notes, but we c

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: > On Aug 6, 2018, at 2:05 PM, Jonathan S. Katz wrote: >> 1. Add to the “docload” script to segment out the release notes and store >> them in a separate table. Perform an “upsert” (i.e. check for an existing >> reference; if it’s there, update any content, otherwise ins

Re: Release note trimming: another modest proposal

I wrote: > Hm, so the only objection I can think of is that this results in the old > release notes only being available on the website; there's no other way > to access them, short of digging around in the git repo. But maybe that's > enough. Actually, a concrete reason why that might not be goo

Re: Release note trimming: another modest proposal

> On Aug 6, 2018, at 3:27 PM, Tom Lane wrote: > > I wrote: >> Hm, so the only objection I can think of is that this results in the old >> release notes only being available on the website; there's no other way >> to access them, short of digging around in the git repo. But maybe that's >> enoug

Re: Release note trimming: another modest proposal

"Jonathan S. Katz" writes: >> On Aug 6, 2018, at 3:27 PM, Tom Lane wrote: >> Actually, a concrete reason why that might not be good is that it results >> in having a single point of failure: once we remove branch N's relnotes >> from the active branches, the only copy of that data is the one in t

Re: Release note trimming: another modest proposal

> On Aug 6, 2018, at 3:37 PM, Tom Lane wrote: > > "Jonathan S. Katz" writes: >>> On Aug 6, 2018, at 3:27 PM, Tom Lane wrote: >>> Actually, a concrete reason why that might not be good is that it results >>> in having a single point of failure: once we remove branch N's relnotes >>> from the ac