public inbox for [email protected]  

help / color / mirror / Atom feed

From: Masahiko Sawada <[email protected]>
To: Jelte Fennema-Nio <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Nathan Bossart <[email protected]>
Cc: [email protected]
Subject: Re: First draft of PG 17 release notes
Date: Tue, 10 Sep 2024 09:52:42 -0700
Message-ID: <CAD21AoAqQJWXX+0a9KZO+sXUdJ3Co1T+Jo_7Wh53Q5YB98rOYA@mail.gmail.com> (raw)
In-Reply-To: <CAGECzQQfRVehQON65qNu-T_1O7VE+aFi0uPgvSEG4PHaijbUiw@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAGECzQQfRVehQON65qNu-T_1O7VE+aFi0uPgvSEG4PHaijbUiw@mail.gmail.com>

On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio <[email protected]> wrote:
>
> On Tue, 10 Sept 2024 at 04:47, Bruce Momjian <[email protected]> wrote:
> > Yes.  There are so many changes at the source code level it is unwise to
> > try and get them into the main release notes.  If someone wants to
> > create an addendum, like was suggested for pure performance
> > improvements, that would make sense.
>
> I agree that the release notes cannot fit every change. But I also
> don't think any extension author reads the complete git commit log
> every release, so taking the stance that they should be seems
> unhelpful. And the "Source Code" section does exist so at some level
> you seem to disagree with that too. So what is the way to decide that
> something makes the cut for the "Source Code" section?
>
> I think as an extension author there are usually three types of
> changes that are relevant:
> 1. New APIs/hooks that are meant for extension authors
> 2. Stuff that causes my existing code to not compile anymore
> 3. Stuff that changes behaviour of existing APIs code in a
> incompatible but silent way
>
> For 1, I think adding them to the release notes makes total sense,
> especially if the new APIs are documented not only in source code, but
> also on the website. Nathan his change is of this type, so I agree
> with him it should be in the release notes.

+1. I think that the increment JSON parser that is already mentioned
in the release note would fall in this type too; it's not a feature
aimed just for extension authors, but it's kind of source and internal
changes IMO. Since the DSM registry feature is described in the doc, I
think it would make sense to have it in the release notes and probably
has a link to the "Requesting Shared Memory After Startup" section.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

view thread (17+ 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]
  Subject: Re: First draft of PG 17 release notes
  In-Reply-To: <CAD21AoAqQJWXX+0a9KZO+sXUdJ3Co1T+Jo_7Wh53Q5YB98rOYA@mail.gmail.com>

* 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