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 20:19:17 GMT
Great! Sounds like we all agree to agree :)

Fil - Sounds good for you to do the initial Release Process write-up, and
then we can ask questions / tweak if necessary afterwards.


On Wed, Jul 31, 2013 at 3:53 PM, Brian LeRoux <b@brian.io> wrote:

> That distinction is important: platforms continue monthly release
> cadence. CLI tools are continuous delivery.
>
>
> On Wed, Jul 31, 2013 at 12:43 PM, Filip Maj <fil@adobe.com> wrote:
> > Agree with both of you: we should be tagging the tooling. Currently we
> > follow the standard monthly release process that we apply to platforms.
> WE
> > should probably change that.
> >
> > +1 to documenting release process. I will take time to do so for cli +
> > plugman
> >
> > Email is the way to go. LEt's not mire ourselves with JIRA issues that
> > committers may or may not receive notifications for. To Anis' point, my
> > approach has been to notify interested parties on a particular
> feature/bug
> > fix on a) the specific JIRA issues and b) the list if it is a sweeping
> > change or a big feature. Sounds like we want to continue with this.
> >
> > So what shakes out here is: we need to figure out what the release
> process
> > is for things that are on a different (more continuous?) release schedule
> > compared to the platform implementations.
> >
> > On 7/31/13 11:54 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
> >
> >>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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message