Re: [PATCHES] Re: [COMMITTERS] pgsql: Stamp releases notes for 8.2.3, 8.1.8, 8.0.12.
On Wed, 2007-02-07 at 13:21 -0500, Bruce Momjian wrote: If there is some value to capturing every change, but still keeping the release notes a readable length, please let me know. If it fixes a real, non-theoretical bug and has been backpatched to a stable release branch, I would say in most cases it is worth documenting in the release notes. Describing every change made in a new feature release (i.e. 8.3.0) would be far too much verbiage, but far fewer changes are made to stable branches. Also, documenting all the significant changes in stable branch releases is valuable to let users identify possible regressions. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Re: [COMMITTERS] pgsql: Stamp releases notes for 8.2.3, 8.1.8, 8.0.12.
Neil Conway [EMAIL PROTECTED] writes: If it fixes a real, non-theoretical bug and has been backpatched to a stable release branch, I would say in most cases it is worth documenting in the release notes. Describing every change made in a new feature release (i.e. 8.3.0) would be far too much verbiage, but far fewer changes are made to stable branches. Also, documenting all the significant changes in stable branch releases is valuable to let users identify possible regressions. Neil has a good point: the documentation policy should be different for updates to stable branches than it is for a new major release. I think Bruce's too small to bother with policy is about right for major releases, but if we've bothered to back-patch something then it's usually worth documenting. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Re: [COMMITTERS] pgsql: Stamp releases notes for 8.2.3, 8.1.8, 8.0.12.
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: If it fixes a real, non-theoretical bug and has been backpatched to a stable release branch, I would say in most cases it is worth documenting in the release notes. Describing every change made in a new feature release (i.e. 8.3.0) would be far too much verbiage, but far fewer changes are made to stable branches. Also, documenting all the significant changes in stable branch releases is valuable to let users identify possible regressions. Neil has a good point: the documentation policy should be different for updates to stable branches than it is for a new major release. I think Bruce's too small to bother with policy is about right for major releases, but if we've bothered to back-patch something then it's usually worth documenting. OK, I am more liberal in adding to a minor release, but I avoid cases where the bug has been around for a long time and the error case is rare. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
