Hi all, Recently, I've noticed that the cordova-cli is misusing the versioning scheme that is used by the phonegap-cli. It's a little confusing, but effective, so let me run through it.
--- VERSION BREAKDOWN --- cordova@x.y.z-a.b.c --- X.Y.Z --- x.y.z is the version of Cordova that is bundled with the CLI. We all know this. --- A.B.C --- a.b.c is the package (semver) version of the cordova-cli node library. Imagine that the cordova-cli could support any version of Cordova, then a.b.c would be the sole version used by the npm package; similar to any other npm package. This version should always go up. --- PROBLEM --- The problem is that the cordova-cli is resetting a.b.c each time it increments x.y.z. For projects that use the node interface of the cordova-cli, this is a problem. a.b.c describes changes to the node programmatic interface, just like any other good node project published to npm. By resetting it, we confuse and hurt developers who depend on the API because they don't know what has changed in the node API. --- BAD EXAMPLE (HOW IT IS TODAY) --- cordova@3.1.0-0.1.0 - first release cordova@3.1.0-0.2.0 - minor node api fix cordova@3.2.0-0.1.0 - what!? Why did the node version reset to 0.1.0? cordova@3.2.0-0.2.0 - minor node api fix cordova@3.3.0-0.1.0 - what!? Node API users must manually discover what changed --- GOOD EXAMPLE --- cordova@3.1.0@0.1.0 - first release cordova@3.1.0@0.1.1 - patch to node package (no node api change) cordova@3.1.0@0.2.0 - minor to node package (backwards compatible api change) cordova@3.2.0@0.2.0 - new cordova release; no node package changes cordova@3.2.0@0.2.1 - patch to node package cordova@3.3.0@0.2.2 - new cordova release; patch to node package cordova@3.3.0@0.3.0 - minor to node package cordova@3.3.0@1.0.0 - major to node package (non-backwards compatible api change) cordova@3.4.0@1.1.0 - new cordova release; minor to node package cordova@3.4.0@1.1.1 - patch to node package I hope this helps to improve the cordova-cli versioning habit. Cheers! Michael
