Joe - would you be willing to write the blog post on Cordova's blog instead of a personal blog? Each cordova blog post does have an author with an optional link.
I think having things on Cordova's blog rather than personal / downstream ones makes things more trusted & discoverable. On Wed, Dec 11, 2013 at 1:27 PM, Joe Bowser <[email protected]> wrote: > 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. > >> >
