Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I suppose we all thought that the change wouldn't bite anyone.

I wasn't expecting such vocal complaints, for sure.

> 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.

			regards, tom lane

Fri, 08 Feb 2002 18:03:53 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Maintaining the list of release changes 
On Fri, Feb 08, 2002 at 06:03:53PM -0500, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.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

Fri, 8 Feb 2002 17:15:26 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: Maintaining the list of release changes
"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> I think the users that screamed about this would like a detailed "every
> user visible change" list, in addition to the highpoints Release notes.

A greppable copy of the CVS logs would satisfy that, assuming that we
maintain a reasonable standard of quality in our commit messages.
David Gould evidently managed to find my commit message about that
array_out change; but I do not know how hard it was for him to look.

Perhaps we should arrange for a nightly cvs2cl run to produce a "CVS
changes since last major release" document on the website.  This might
also help answer Peter's concern about visibility of work-in-progress.

> 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'.

I don't think that's a helpful criterion.  "Does it potentially break
any application code?" might be a helpful criterion.

New features that don't pose backwards-compatibility issues probably
need a different set of criteria to decide if they merit mention in
release notes.

			regards, tom lane

Fri, 08 Feb 2002 18:35:03 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Maintaining the list of release changes 