cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <>
Subject Re: Publishing to npm
Date Wed, 31 Jul 2013 18:26:03 GMT
I agree with Fil. I am ok with tagging every npm release but I don't
think creating a Jira issue for minor point releases will be really

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