cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: RELEASENOTES.md and coho
Date Wed, 11 Dec 2013 21:54:52 GMT
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