On Wed, Dec 11, 2013 at 10:23 AM, Andrew Grieve <[email protected]> wrote: > 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? >
Yes, because until recently that's what we did. Shaz wrote the iOS one, and either Simon or I wrote a blog post about Android. These would then be syndicated and put on the phonegap.com blog. We used to have a perfectly good solution to this problem which went away roughly around when 3.0.0 came out. This mostly went away because of time constraints and the fact that my own blog sucks ass and needs to be migrated to a real server. I think we need to go back to this. Also, this is a good way for people to get exposure and get their name out there, so there's way more reward for doing this than just writing RELEASENOTES.md which will be buried in the release and may or may not be read. > > 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. >>
