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.
