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 22:06:09 GMT
Awesome! Case closed.


On Thu, Dec 12, 2013 at 8:54 AM, Steven Gill <stevengill97@gmail.com> wrote:

> I have already been running git log, curating and posting to the blog when
> I do releases. :)
>
> Syndication would be nice to setup.
>
>
> On Wed, Dec 11, 2013 at 1:34 PM, Brian LeRoux <b@brian.io> wrote:
>
> > 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