cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: RELEASENOTES.md and coho
Date Wed, 11 Dec 2013 18:41:35 GMT
On Wed, Dec 11, 2013 at 10:38 AM, Andrew Grieve <agrieve@chromium.org> wrote:
> 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.

If I have to, I think we should syndicate instead so we don't
copy/paste content.

> I think having things on Cordova's blog rather than personal / downstream
> ones makes things more trusted & discoverable.

I disagree.  We should have Cordova's blog syndicate other known
blogs.  I don't think anyone actually reads the Cordova blog.  I
haven't until today.

Joe


>
>
> On Wed, Dec 11, 2013 at 1:27 PM, Joe Bowser <bowserj@gmail.com> wrote:
>
>> On Wed, Dec 11, 2013 at 10:23 AM, Andrew Grieve <agrieve@chromium.org>
>> 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 <jsoref@blackberry.com>
>> 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.
>> >>
>>

Mime
View raw message