cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Publishing to npm
Date Wed, 31 Jul 2013 18:07:21 GMT
I'd like to avoid a voting / consensus process _for EVERY RELEASE_ if
possible.

We are including the tools in our monthly releases, and that I think is
good enough in terms of following Apache process. This way there's lazy
consensus per minor release.

Being able to publish revisions to npm and fix bugs that way has been a
positive experience for devs as well as users. Don't know why we would
want to change that. Quick patch releases have been great for building
confidence in our tools within our community.

Filing a JIRA issue for every patch release is super overkill and doing
lazy consensus for that seems even worse. We've had 5 patch releases so
far since 3.0.0. Lazy consensus requires 72 hours of email fermentation.
So that would mean we can release a max of 10 releases per month? Doesn't
make sense to me.

Tagging every npm release makes a lot of sense for all of our tools /
plugins, but to be noted that we release tools/plugins differently than
platforms, so figuring out the differences there would be a good idea.

On 7/31/13 10:54 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:

>We're telling people to install plugman & cordova via npm, but we're
>publishing updates to npm on a regular basis without any sort of release
>process. True?
>
>Or maybe npm has a way to publish dev versions that people won't pick up
>by
>default?
>
>Either way, I'll start the ball rolling here:
>
>For a of any of our pieces (npm, plugins, platforms), I think it's a must
>to have a wiki page documenting the release process. We have this for
>platforms (although it needs updating now that we're 3.0), but we need
>this
>for plugins & npm modules as well now.
>
>A release process should :
>1 - include testing procedures to follow when releasing
>2 - be detailed enough that anyone can perform the release
>3 - include a JIRA release issue to track the occurrence of the release.
>4 - include creating a git tag for the release
>
>Anything else?
>
>
>All releases should also have a vote (even if it's recorded through a JIRA
>issue). This is stated in the apache rules, but also serves the purpose of
>making a release a team release instead of an individual release). I'd
>like
>to see a release vote happen as an email that includes:
>1 - Main motivation for the release (even if it's just "time has passed")
>2 - The changelog since the previous release.
>
>Make sense?
>
>Andrew


Mime
View raw message