> I've been pushing this agenda for a few releases now, but some people have
> been, er, boycotting it. I think, too, that release notes *must* be
> written incrementally at the same time that the feature change is made.
> This is the only way we can get accurate and complete release notes, and
> the descriptions could even include some context, some motivations, etc.
> We have release cycles of 10 months, and there is no way we can make
> sensible release notes by gathering individual commit messages over that
> period of time. Heck, ECPG has a full Informix compatibility mode and
> there is no mention of that anywhere, because there was no commit "Add
> Informix mode."
>
> I suggest we just do it like the documentation: If you don't document it,
> it doesn't exist. If you don't write a line for the release notes, it
> doesn't exist either.
I tend to agree it. For every release I and my colleague have been
working on creating detailed release notes (of course in Japanese),
otherwise we cannot tell people what are changed, added or fixed since
there is little info in the official release note. This is painful
since we have to dig into the mail archives and cvs commit messages to
look for what each item of the official release note actually
means. These work take at least 2 to 3 weeks with several people
involved. The hardest part is what are fixed. The only useful
information seems to be the cvs commit messages, however typical
messages are something like "see recent discussions in the mail
archive for more details". This is not very helpful at least for
me. Once I proposed that we add a sequence number to each mail and the
commit messages point to the number. This way we could easily trace
what are the bug report and what are the actual intention for the
fix. For some reason noboy was interested in. Maybe this is due to
"coulture gap"... (In Japan giving a sequence number to each mail in
mailing lists is quite common).
--
Tatsuo Ishii
