Tom Lane writes:
> I agree completely, and was about to make a similar proposal. However,
> I'm not entirely sure where "the release notes" actually are, nor which
> is the master copy. Also, I'd prefer not to have to deal with SGML
> markup for them.
The release notes are in the file release.sgml. You don't really have to
deal with any markup there. Look at the source under sect2 "Changes"; you
only need to insert a line there. (Well, not there. A new section will
be created.) Grouping this into useful categories and creating the
"highlights" at the top can be done later during the usual revising and
editing.
> What I'd suggest is that we keep a plaintext file somewhere near the
> top of the CVS tree (in doc/ perhaps) that developers append
> release-notes items to as the work is completed. At the end of each
> development cycle, Bruce can prepare the "nice looking" notes from that
> source and then reset the file to empty for the next cycle.
This (and later CVS log based ideas) don't really address my point #1:
keeping users informed. You might underestimate that. Plenty of users
would really like to try out development snapshots for their new projects,
or see if they compile, verify new features early, or just to play around.
But that's a lot harder if they don't know what's in there.
Secondly, why do double work if you can just do it right the first time?
We've been doing an excellent job lately about keeping the documentation
current. This is really the same corner, but it's even more fundamental:
If you know what changes have been made since the last release you can
easily check if those changes have made it into the documentation. I'm
not suggesting that we become laxer about documentation updates because of
this, neither do I want strict "every patch must update the release notes"
policies. Just keep in mind that at some point, when you update the
documentation (meaning you feel your feature is reasonably complete to the
point that you want to let it loose), add a line to the release notes to
let people know it's there. That's it.
--
Peter Eisentraut peter_e@gmx.net
