cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Publishing to npm
Date Wed, 31 Jul 2013 18:42:54 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message