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:29:08 GMT
I think Anis meant patch releases (we already create jira issues for minor
releases, which come every month)

On 7/31/13 11:26 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:

>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
>beneficial.
>
>On Wed, Jul 31, 2013 at 11:07 AM, Filip Maj <fil@adobe.com> 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" <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