cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: and coho
Date Wed, 11 Dec 2013 18:27:47 GMT
On Wed, Dec 11, 2013 at 10:23 AM, Andrew Grieve <> 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 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 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 <> 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 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.

View raw message