Re: Maintaining the list of release changes

"Ross J. Reedstrom" <reedstrm(at)rice(dot)edu> writes:
> I'm partial to a combo - a 'USER VISIBLE CHANGES: <yes|no>' line in CVS
> commit logs (put it in the template, default to yes?) and every 'yes'
> submit _must_ patch the cumulative release file.

I find it hard to imagine a patch that doesn't create *some* kind of
user-visible change, at some level. The question here is whether it
rises to the level of needing an entry in the release notes. If we
wanted a commit-by-commit release history we'd just tell people to read
the CVS logs; in practice that's no help. The point of release notes is
to hit the high spots, and that requires a certain amount of judgment.

So I don't think a mechanical "you must provide this" rule will help
much. We should rely on the judgment of the committer to decide whether
a release note is warranted. What we want is a reasonably simple way
for the committer to provide a draft note, and a mechanism to ensure
that Bruce doesn't miss the note later.

In the case that started this thread, I had actually provided material
for a release note in the CVS commit entry, but Bruce had skipped over
it because he didn't think it important. The missing link was that
I didn't have a way to plaster a "this is important" label on the
commit message.

Oh, here's another thought: including an explicit patch of the
pending-notes file in submissions won't work very well, since that part
of the patch will surely fail to apply if it's even a few days old.
It'll have to come in as separate text that the committer inserts into
the pending-notes file when he commits. From this perspective, it might
be a lot easier to put the notes into CVS commit messages; there'll be
fewer problems with commit collisions.

regards, tom lane