Yep, my main concern is communicating what's changed to our users for
releases. Whether this file actually exists, or when it's updated, I care
less about.

Joe - if you don't think a single blog post is a good way to communicating
this, what's a good alternative? Should we have each platform write a blog
post as a part of the release instead of release notes?


On Wed, Dec 11, 2013 at 11:05 AM, Josh Soref <[email protected]> wrote:

> 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.
>

Reply via email to