cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: RELEASENOTES.md and coho
Date Wed, 11 Dec 2013 18:58:13 GMT
Thanks for chiming in Dan!


On Wed, Dec 11, 2013 at 1:48 PM, Dan Moore <moore234@yahoo.com> wrote:

> 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.
>

Absolutely Agree.


>
> 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.)
>

Actually when we first discussed the cordova blog and how to post what,
this exact suggestion came up.  We all agreed it was a good idea (well, at
least those who decided to voice opinions at the time..).

At the time we mentioned that "release notes" are clearly the result of a
group effort on platforms/plugins, and thus a cordova centric blog post
should go out about it (but still posted from one specific Author with name
attribution).

For other types of posts that come from community members' personal blogs,
like user guides, or tips and tricks, we should absolutely syndicate.  I
don't think we've been doing this, though.  I'm not sure that we even
discussed the way to submit something for syndication.  Maybe we should
start on that, or maybe we should just leave it up to the phonegap blog,
I'm not sure.


>
> 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