OK, I will attempt to draw together this information as currently
stands. If this makes any sense, we can discuss what the
requirement/process is for regular maintenance (daily/weekly/monthly
etc).

Understood to mean "changes in next release (current progress)" - items
that have been completed/committed since last release, for the purpose
of informing developers/testers what's new PRIOR to full release.

Leaving unobstructed the functions of
- TODO list - a combined list of desired work items (Bruce)
- Release Notes - final list of features of a release (Bruce)

This should help alpha testing, which should allow more control of what
actually does get released (and therefore what the contents of Release
Notes should be)

Best Regards, Simon
-----Original Message-----
From: Tom Lane
Sent: Friday, January 23, 2004 20:40
To: Neil Conway
Cc: simon@2ndquadrant.com; 'Jan Wieck'; 'Postgresql Hackers'
Subject: Re: 7.5 change documentation

Neil Conway <neilc@samurai.com> writes:
Tom Lane <tgl@sss.pgh.pa.us> writes:
In theory there should be a section at the head of release.sgml
mentioning the major changes done-so-far, but for various reasons
this hasn't gotten installed in the 7.5 branch yet. (Look at the
CVS versions during 7.4 development to see how we did it last
time.)
Well, keep in mind we didn't do it very effectively in 7.4 :-) The
vast majority of changes weren't recorded there, and the ones that
were had to be fleshed out quite a lot in the actual release notes.
The last time that someone (Peter and myself, IIRC) suggested that
we
really incrementally maintain the release notes during the
development
cycle, Bruce said that he personally finds it more comfortable to
summarize the CVS changelogs all at once shortly before we release
the
first beta. AFAIR that's where the discussion ended.
It's fine with me if Bruce prefers to build the release notes directly
from the change logs. As I saw it, the purpose of the temporary list of
things-done-so-far is not to be the raw material for the release notes.
It's to let alpha testers know about major changes that they might want
to test. As such, it's fine that it's incomplete.

The other way we could handle this goal is to be a tad more vigorous about
checking off items as "done" in the TODO list. However, Bruce generally
doesn't bother to make a new entry in the TODO list if someone does
something that wasn't in the list to begin with, and so I'm not sure
it's the right vehicle.

regards, tom lane

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 23 of 29 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedDec 18, '03 at 5:15p
activeJan 28, '04 at 12:31a
posts29
users11
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase