Looking through peoples responses on this thread and the project version thread, many people have been pushing for a bigger jump in version number for the CLI.
Chatting with Shaz, he is very concerned about support issues coming in with users being very confused about versions. By having a big seperation between platform versions and cli version, that will at least remove the connection between the two. I'm leaning towards a bigger jump now. Proposal: CLI becomes version 10.0.0 On Fri, Oct 3, 2014 at 3:02 PM, Brian LeRoux <b...@brian.io> wrote: > Maybe pinning platforms and the CLI wasn't so bad after all. > On Oct 3, 2014 2:34 PM, "Treggiari, Leo" <leo.treggi...@intel.com> wrote: > > > I agree that this is, and will be, confusing. It was confusing today in > > our own discussions in our own team (who are, in general, fairly Cordova > > savvy) to be talking about the Android store issue related to "Cordova > > 3.5.1". E.g. what did it mean to be talking about "Cordova 3.5.1", and > > what would a user need to do to get the fix? What I took away was that a > > user would need Cordova CLI 3.5.0-0.2.7. However, I wouldn't be > surprised > > if you told me that was wrong... > > > > Anyway, a completely different (and possibly immediately dismissible) > > idea. What if a Cordova CLI version number was the same as the highest > > version number of the platforms supported by that Cordova CLI version. > > E.g. if the latest highest platform version was Android 3.5.1, then the > > Cordova CLI version would be 3.5.1. The supported other-platform version > > might be lower - e.g. Windows 3.4.2 (totally made up version number...). > > > > That doesn't instantly solve all problems. What if the next platform > > release after Android 3.5.1 was Windows 3.4.3? Cordova CLI can't remain > at > > the highest version number. So would Cordova CLI become 3.5.2 or > 3.5.1-1? > > Should the Windows release be 3.5.2? Are there a specific set of features > > associated with a specific platform major version number? It seems that > a > > platform release named 3.x.y is expected to have a certain set of > features > > implemented. Is a platform release named 3.4.x expected to have a > certain > > set of features and a platform named 3.5.x expected to have those > features > > plus some additional feature? > > > > In general, what can a user expect these version numbers to mean. E.g. > if > > I as an app developer want to use a particular recently added feature on > > multiple platforms, how do I determine which versions of which platforms > > support the feature and which Cordova CLI version gives me what I want? > > > > Sorry, but it is confusing... > > > > Leo > > > > -----Original Message----- > > From: Marcel Kinard [mailto:cmarc...@gmail.com] > > Sent: Friday, October 03, 2014 1:56 PM > > To: dev@cordova.apache.org > > Subject: Re: Independent platform release summary > > > > If a bump to major indicates an API change, how is that visible to users? > > Do users look at the CLI version as "the version of Cordova", or are we > > expecting users to look at the version of every Cordova component to > > understand where majors got bumped? While I agree the latter is more > > correct technically, I think users have been and are currently assuming > the > > former. It would take some education to switch that. > > > > On Oct 2, 2014, at 7:51 PM, Andrew Grieve <agri...@chromium.org> wrote: > > > > > I don't think it's necessary to bump CLI major when platforms bump > major. > > > Platforms and CLI are linked only superficially anyways. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > >
