Michal wrote: > when doing a release, you usually have to make a > mental note of what is worth testing, which usually means going through the > changelog anyway, which means it isn't really adding serious time to the > release process.
> However, this shouldn't be codified into our processes, > and should be the responsibility of whoever is doing the blog post, not > whoever is doing the release, and those two aren't always the same. +1 One problem is that the release blog seems to be pro forma and hurried. I've written release notes with blog entries. Doing them well is worthwhile. A few things that can help: 1. Tagging issues at filing / analysis / resolution with a release note indicator (yes, no) 2. Working on the release notes before the release process finishes - you probably already have 90% of the release fixes known a few days before d day. The last fixes can be yes/no as they're committed. 3. It's important not to have "Fixed x; backed out fix for x". People reading release notes don't care about the process between the previous release and now, they want a clear indication of what has actually changed. > So lets remove the requirement, and I guess the RELEASNOTES.md file from the > repos? +1 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
