Re: Maintaining the list of release changes

On Fri, Feb 08, 2002 at 06:03:53PM -0500, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I suppose we all thought that the change wouldn't bite anyone.
>
> I wasn't expecting such vocal complaints, for sure.

I think the users that screamed about this would like a detailed "every
user visible change" list, in addition to the highpoints Release notes.

> > Tom, at the time, did you think it should be mentioned in the release
> > notes?
>
> I can't recall if I thought about it in that way. If I had, I would
> have said "yes", but I don't recall if I considered the point. I've
> always made a habit of writing reasonably detailed commit messages and
> then leaving it to you to decide whether a release note is needed.
>
> Part of the point of this discussion, I think, is just to make sure that
> committers consider "should there be a release note for this change?"
> every time they commit. Thinking about that, and writing down the
> appropriate info immediately if a note is needed, are the critical steps.

And having guidelines for the developers that describe the simple
questions to ask themselves when answering 'does this deserve a release
note'. It's not about advertizing: it's about documenting changes, so the
DBA can grep for likely words of something breaks, such as (in this case)
"array".

Tom, you said 'every change is user visible'. I think, for this purpose,
only things that modify existing behavior (input or output) in kind,
not merely quality, are 'visible'. A patch that speeds up (or slows
down!) query processing by 100 fold is certainly user visible, but not
for the purposes of reporting release changes. New functionality is not
'user visible'.

Ross