public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jonathan S. Katz <[email protected]>
To: Tom Lane <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Magnus Hagander <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: [email protected]
Subject: Re: Release note trimming: another modest proposal
Date: Mon, 4 Feb 2019 17:13:21 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<CABUevEzX3dq-uUeMR0mSnCj4B6TK3v4QuQKKsf6Oz+ZdyRHMZg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On 2/4/19 4:25 PM, Tom Lane wrote:
> "Jonathan S. Katz" <[email protected]> writes:
>> On 2/4/19 11:12 AM, Tom Lane wrote:
>>> It's not quite clear to me what the policy would be for removing
>>> back-branch links from this list when old versions drop out of support.
>>> Should we go back and remove them in surviving back branches, or just
>>> change HEAD?
> 
>> Yeah, that was one of my first thoughts as I reviewed the patch. It's
>> one of those "once-a-year" things that are easily forgotten (e.g. with
>> EOL warnings, which is why we updated a few things around that). But as
>> long as they're added to the process of wrapping for the release, it
>> does not sound like its a huge burden.
> 
> After a bit more thought, I'm inclined to propose that the policy be
> that we *don't* update the surviving back branches for branch retirement.
> The new wording in release.sgml should be adjusted to clarify this,
> along the lines of

...so I guess in turn, we would not update back branches with newer
releases as well, i.e. adding references about 12 to 10? That makes
sense, and eases some of the burden on releases.

> 	Release notes for prior release branches can be found on the
> 	PostgreSQL web site.  At the time of release of version 12,
> 	these were the supported prior release branches:
> 
> 	<list of direct links, as before>
> 
> 	Release notes for older branches can be found at
> 	<link to docs/manuals/archive/>.
> 
> In this way, the prior-release notes section just provides some handy
> links for recent past releases, and isn't purporting to offer
> up-to-the-minute info on what's in support.

+1

Jonathan



Attachments:

  [application/pgp-signature] signature.asc (833B, 2-signature.asc)
  download

view thread (58+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Release note trimming: another modest proposal
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox