cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: Publishing to npm
Date Wed, 31 Jul 2013 18:20:20 GMT
I was under the impression that npm releases where unofficially
supported officially by a lead committer. (OK I'M BEING A SMARTASS!)

But it is true that anyone can publish a package to npm, it is the
wild west, and a separate concern from apache cordova releases. Yes,
our docs recommend it. I do too. Way easier workflow for development.

As Fil mentioned we should maintain responsiveness and agility here.
I'm certain that Andrew isn't suggesting otherwise either. Lets find
consensus on the best way to release that satisfies those goals.

On Wed, Jul 31, 2013 at 11:07 AM, Filip Maj <> wrote:
> 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" <> 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
>>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
>>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
>>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?

View raw message