cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: missing documentation and missing major version bump
Date Wed, 30 Jul 2014 02:45:24 GMT
Throwing out another option: can we just patch cli now to pass arguments on
like it used to, even with the new nopt?  Failing that, I don't mind
reverting the config changes and releasing tools again, assuming we're
going to get 4.0 out soon anyway.

Josh: RE CI -- I look forward to your patch for getsdk.  Certainly Andrew
brought that up at the meetup as something that would be awesome to have.
 Until then, if BB doesn't put up some form of CI and also doesn't have the
cycles to run tests and report on releases, the regressions for BB will
continue.  (Sorry, but we've invested a shit ton of time on testing/CI here
already, and if you cannot find the cycles, its unreasonable to expect that
we will).

-Michal


On Tue, Jul 29, 2014 at 8:23 PM, Carlos Santana <csantana23@gmail.com>
wrote:

> if you know of assumptions on cordova cli like passing extra arguments down
> to the platform scripts (i.e. emulate), this is something that can be added
> to the unit tests for cordova-lib, this way it's part of the CI tests with
> "npm test"
> you can mockup the expected call down to the platforms scripts.
>
> no need to add integration test, just to test an API contract.
>
> lesson learned if you expected cordova cli to work in a certain way, then
> add unit tests this way a change like this can be capture when someone
> changes the behavior
>
>
> On Tue, Jul 29, 2014 at 6:32 PM, Josh Soref <jsoref@blackberry.com> wrote:
>
> > Michal wrote:
> > > Current cli is cadver-semver and if even if we had bumped the semver
> > MAJOR it would not have mattered.
> > > If you were using semantic version matching in
> > your package.json for cli dependancy,
> > > the current scheme does not match the way you expect.
> > > Josh your suggestion is that we should have used our ‎cadver number as
> a
> > semver this last release, but its never been used that way.
> > > That is exactly the point of the latest plan from last hangout to
> > > address release process to dump the cadver portion of cli (see
> discussion
> > on other threads if 4.0.0 is the right initial semver).
> >
> > I'm asking us to hurry up and ship a 4.0.0 and then ship something which
> > is a cad-semver (3 . something) with the nopt stuff reverted.
> >
> > I'm not personally using package.json with cli, and I'm certainly not
> > using grunt-cordovacli, but people apparently do. And what we (Cordova)
> did
> > broke them.
> >
> > > p.s. If BB relied on --someblackberryspecificoption working, it would
> > have
> > > been useful to bring up during last tooling release vote window.
> >
> > Sorry, we've been focusing on releasing our product and I haven't had the
> > resources to test the tooling releases.
> >
> > I usually assume that webworks foo and cordova foo will do the same
> thing,
> > and they often do. Unfortunately (or fortunately), in the case of run,
> > webworks talks to cordova-lib of somehow similarly skips the option
> parsing
> > that trips people up here.
> >
> > > Better yet, set up a local CI that automatically reports setup/build
> > failures, as
> > > we use here for ios&android vanilla&cca and has been quite valuable.
> >
> > I'm somewhat -1 on this. We lost a lot of time trying to set up a
> buildbot
> > or something similar for someone, and that went nowhere. The round trip
> > time was awful. Setting up BlackBerry 10 is pretty easy. If someone who
> > understands the CI system of the day wants to do it, I'd encourage them
> to
> > do it. I'd be happy to help with any specific questions (or find someone
> > else who can).
> >
> > What I'm willing to do is look into:
> > 1. Writing "(cordova-cli) cordova getsdk platform" (for at least android
> > and blackberry 10)
> > 2. Writing "(cordova-cli) npm run test-platforms" which would getsdk for
> > each platform, get the platform and run a well known entry point for that
> > platform to get its test directory ‎and then run the commands it
> specifies.
> > That way whomever sets up CI can just teach it to run test-platforms and
> > whenever someone adds a platform, they don't have to waste time trying to
> > set up CI, just fill in the blanks (getsdk, get-tests).
> >
> > (this is on top of them writing the platform, the metadata parser, and
> > support for plugman)
> >
> > But, tentatively, 1 and 2 are behind me refactoring metadata parser and
> > plugman platform bits into their respective platforms.
>
>
>
>
> --
> Carlos Santana
> <csantana23@gmail.com>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message