cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Moore <moore...@yahoo.com>
Subject Re: RELEASENOTES.md and coho
Date Wed, 11 Dec 2013 18:48:59 GMT
Hi folks,

As a user, having all the release information in one place would be fantastic.  I understand
your desire to have a rapid release schedule (documented, as best as I can tell, here: http://phonegap.com/2012/04/12/rolling-releases-how-apache-cordova-becomes-phonegap-and-why/
).

But for normal app developers, having a clear understanding of what they get when upgrading
(what features, bug fixes, improvements, etc have happened since the last release) is extremely
helpful.  Doing this will probably increase adoption of the latest versions of cordova.

Another option different from having everything on one blog would be to do something like
what phonegap.com/blog does--a mix of content hosted there and content excerpts pulled in
from other blogs.  (I don't know the exact mechanism nor how hard it would be to implement,
though.)

Cheers,
Dan





On Wednesday, December 11, 2013 11:39 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.

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