cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: RELEASENOTES.md and coho
Date Wed, 11 Dec 2013 18:38:29 GMT
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message