On Mon, Sep 9, 2024 at 11:29 PM Jelte Fennema-Nio <postg...@jeltef.nl> wrote: > > On Tue, 10 Sept 2024 at 04:47, Bruce Momjian <br...@momjian.us> 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
