cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: RELEASENOTES.md and coho
Date Wed, 11 Dec 2013 21:34:42 GMT
Ok, so I feel we have some consensus that:

- release notes are sometimes helpful for some types of people
- release notes belong on the blog and not in the source tree
- we need a champion to run git log, curate, and post said release notes to
the blog

Sound about right?

(I feel blog syndication thing is a different issue.)


On Thu, Dec 12, 2013 at 5:58 AM, Michal Mocny <mmocny@chromium.org> wrote:

> 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