Re: Maintaining the list of release changes
От | Peter Eisentraut |
---|---|
Тема | Re: Maintaining the list of release changes |
Дата | |
Msg-id | Pine.LNX.4.30.0202081754180.689-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Maintaining the list of release changes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Maintaining the list of release changes
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: