cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Publishing to npm
Date Wed, 31 Jul 2013 18:54:59 GMT
I think that is what we have been doing so far. We have been sending
an email out and waiting around 24 hours to give everyone a chance to
chime in.

As far as process, this is how I have been doing it:
- Implement a feature/patch
- Write/run tests.
- Push to master.
- If it's a patch that fixes an issue then bump the version push it to
npm. Otherwise wait for next patch to do that.

Missing: I think that every time we bump a version we should also tag
that version.

-a

On Wed, Jul 31, 2013 at 11:42 AM, Andrew Grieve <agrieve@chromium.org> wrote:
> Right - yes, my goal is not to slow things down. Rather - if you go on
> vacation, I'd like the releases to keep coming and not stop with there
> being no instructions on how to do them (or worse - me pushing to npm
> incorrectly and breaking the world). E.g. are you pushing master? or are
> you working off of a 3.0.x release branch that's just for bugfix
> cherry-picks.
>
> I would like to increase visibility of releases though. I know you often
> email out when you update npm, but it's a lot of work to know what you've
> released. E.g. I know Anis is working on the registry, and in my eyes
> that's not a patch version type release. But has it gone out to npm
> already? Bug fixes are fine for patch releases, but new features are not.
>
> I actually dislike using JIRA for releases quite a bit. Maybe an email
> would suffice? I do think it would be worth emailing before releasing
> though. Even if it delays things 24 hours (I agree 72 hours seems
> excessive).
>
> The voting is not very useful for this project I don't think, but a second
> set of eyes goes a long way for sanity-checking what goes live. Maybe the
> npm process could involve getting agreement / sign-off from 2 devs?
>
>
>
> On Wed, Jul 31, 2013 at 2:29 PM, Filip Maj <fil@adobe.com> wrote:
>
>> 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