cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <>
Subject Re: Independent platform release summary
Date Thu, 09 Oct 2014 21:27:01 GMT
How about 1.0.0 for the CLI version?


On 10/9/2014 4:13 PM, Steven Gill wrote:
> I think vladimir fixed the bug. We just need to release now.
> Only thing holding back the release now is consensus on the version of the
> cli. It seemed like most people were leaning toward 10.0.0. Should I move
> forward with that? I would just have to branch + pin deps
> Leo the documentation version dropdown box would be tied to cli version. It
> still makes sense to copy over platform documentation into platform repos
> and maybe copy it into docs during generation time.
> As for plugin pinning, plugins have more to do with platforms. I wouldn't
> say they aren't tied to the cli at all. I understand your point though. So
> far, we haven't had any plugins that won't work with previous versions (As
> far as I know). We should really fix the engine stuff for plugins so we can
> keep track of what platforms they work for. I'd like us to give warnings to
> users to update their plugins if newer versions are out. Cordova info
> should also dump what versions of plugins you have installed if it doesn't
> already. In combination with cordova --save & cordova --restore, we should
> be able to recommend a workflow that is easily reproducible on any machine.
> On Thu, Oct 9, 2014 at 1:44 PM, Chuck Lantz <> wrote:
>> Okay - so - there's a pretty nasty CLI blocker bug right now.  Plugins
>> with dependencies don't install (this affects all platforms).  In my
>> opinion, we need to get a CLI release out really soon.  Are we closed on
>> this topic, or do we need to look at doing the old process to get this out
>> the door while we are still talking?
>> There are also a series of other bugs in the currently tagged "3.6.4"
>> platforms for Android, Windows, and Windows Phone 8.  These can be handled
>> independently, but the CLI bug can't.
>> -Chuck
>> -----Original Message-----
>> From: Treggiari, Leo []
>> Sent: Thursday, October 9, 2014 12:23 PM
>> To: Michal Mocny
>> Cc: Marcel Kinard; dev
>> Subject: RE: Independent platform release summary
>> I'll have to admit that this seems a bit weird.  That is, independent
>> versions of the CLI and platforms, with a "Cordova release" named
>> "something" - e.g. a date?
>> Imagine a user wants to know whether the new whitelist entry in config.xml
>> is supported in the versions of CLI and platforms that they have - assuming
>> they understand the distinction between the CLI and platforms to begin
>> with.  They use some command to list the versions of the "things" (CLI and
>> platforms) they have installed.  They go to the individual documentation of
>> the "things" and try to figure it out.
>> The way the Cordova documentation works today is nice with the combo box
>> where I can select a Cordova version - 3.6.0, 3.5.0, ...  What would the
>> combo box contain in the new versioning scheme and how many entries would
>> there be?  Are the answers "dates" and "lots of dates"?  Or would there be
>> no Cordova version documentation other than an explanation of how to get
>> the list of "things" you currently have and where to find the documentation
>> on them.
>> To "pin" or not to "pin.
>> Note that, to me, the pinning choice defines what happens when I use
>> "cordova {plugin | platform} add foo" with no specific version specified.
>> I've understood, so far at least, that plugins are not pinned (an add
>> always fetches something) and platforms are pinned to a CLI version (an add
>> tells the CLI that I will be using that platform (already installed) for
>> this project).  Everything I have read which includes 1 book and the
>> on-line project documentation, suggest that, even if not stating it
>> explicitly.  E.g. plugins talk about "fetching" and platforms don't.  There
>> is a way to fetch a specific version of platform support.  That's good and
>> if I do that it is up to me to understand the compatibility of the specific
>> version I requested.
>> Is this true?  If so then the npm cordova behavior seems weird.  That is,
>> if I "npm install cordova" I get a set of pinned platforms.  If I "npm
>> update cordova", I get a new CLI and nothing else - i.e. not the platforms
>> that were pinned to that version of the CLI?
>> Should the plugin and platform 'pin' behavior be the same?
>> Should both be pinned?  Some may find this alternative "blasphemous" but
>> the core plugin versions tested with a version of the CLI could be pinned
>> to the version of the CLI.
>> Should both not be pinned?  It would be more consistent and if users are
>> OK with plugins being unpinned, why not platforms?
>> But maybe plugins and platforms are different.  Plugins are purely
>> run-time code.  Platforms are primarily tooling with some run-time code.
>> Does that difference make the current pinning behavior the best choice.
>> Maybe, but personally I would prefer both to be pinned - i.e. I install a
>> version of Cordova, and until I update it, every time I add a platform or
>> 'core' plugin, I get the same thing.
>> Leo
>> From: [] On Behalf Of Michal
>> Mocny
>> Sent: Wednesday, October 08, 2014 1:47 PM
>> To: Treggiari, Leo
>> Cc: Michal Mocny; Marcel Kinard; dev
>> Subject: Re: Independent platform release summary
>> With this direction, there is no single number.  Users should not
>> functionally care about CLI version, so there will just be the platform
>> versions that matter, really.
>> Downstreams can of course put labels on combinations of versions, so
>> "PhoneGap 4" may be Android 4, iOS 3.8, and etc.
>> On Wed, Oct 8, 2014 at 4:39 PM, Treggiari, Leo <
>> <>> wrote:
>>> Did I miss anything?
>> I don't think we closed on this (I had to leave the meeting a little
>> early) but a remaining question is how to version what we (and users) call
>> "Cordova".  Assuming a "Cordova" version is a point in time collection of
>> the latest CLI version + platform versions + plugin versions.  Is the
>> Cordova version semver (using what algorithm with respect to its contained
>> components) or is that what you meant by  ""latest as of Oct 2014" or
>> something".
>> Thanks,
>> Leo
>> -----Original Message-----
>> From:<> [mailto:
>><>] On Behalf Of Michal Mocny
>> Sent: Wednesday, October 08, 2014 1:13 PM
>> To: Michal Mocny
>> Cc: Marcel Kinard; dev
>> Subject: Re: Independent platform release summary Thanks everyone for
>> participation in what was a long and grueling discussion.
>> Summary of current proposal:
>> - Cad-ver is dead.
>> - Everything moves Sem-ver, with platforms continuing from current
>> versions and diverging over time.
>> - CLI potentially gets a significant version bump to showcase this reset
>> (to 5.0 or 10.0, not yet settled)
>> - Pinning default platform versions *will* continue for the time being,
>> but it will be trivial to override the default.
>> - Platforms will have CLI <engine> tag equivalent (unclear yet if as node
>> peerDependency or otherwise) so devs will know when they need to
>> upgrade/downgrade CLI for non-default platform versions.
>> - After a platform update, eventually CLI will release to "pin" the new
>> default, and bump its PATCH/MINOR version (unless CLI had a functional
>> update at same time that requires a larger bump).
>> - After you update CLI, your existing projects don't change & platform
>> upgrades remain explicit, but you will now get warnings if your installed
>> platforms are older than the CLI pinned versions.
>> - Event MAJOR changes to platforms are not MAJOR updates to the CLI,
>> unless there is an actual breaking change to the CLI tool (i.e. new CLI
>> will no longer work with the currently installed platform).
>> - Platform and CLI docs have to split out and be released & versioned
>> alongside each (like plugins).  Cross references from one to the other will
>> only be needed in a few places.
>> Note: The CLI-Platform compatibility story is functionally no different
>> than we have today.  If you upgrade your CLI and there is a breaking
>> change, you will have to re-create your projects or downgrade CLI again.
>> Now we plan to be more explicit about it and offer warnings.
>> Note: There is no concept of a "fancy-pants" release other than to say
>> "latest as of Oct 2014" or something.  Platforms don't have a single common
>> set of functionality, so CadVer was somewhat misleading already in that
>> sense.  We could introduce a concept of "API Level" for exec bridge or
>> something for use by plugins, but not sure that has value.
>> What wasn't covered that came to mind after the fact:
>> - When there is an update available for CLI, should we give a warning to
>> update? (this is useful, but isn't common for npm modules.  I think we
>> already do this from plugman when you try to publish plugins?).
>> Did I miss anything?
>> -Michal
>> On Wed, Oct 8, 2014 at 12:35 PM, Michal Mocny <<mailto:
>>>> wrote:
>>> External Public link for those that just want to watch/chat:
>>> Hangout link to join the conversation:
>>> K0jsM4NlmGy5kbLsPIW3SnOsUEIQ?authuser=0&hl=en
>>> See you in 30 minutes.
>>> On Wed, Oct 8, 2014 at 12:33 PM, Michal Mocny <
>> <>> wrote:
>>>> +dev list again
>>>> Not everyone could make 1pm, not everyone could make 2pm.  While I
>>>> don't think we need a full 2 hours, I'm hoping to start late and end
>>>> early -- proving opportunity people to pop in at either time and chime
>> in.
>>>> On Wed, Oct 8, 2014 at 12:18 PM, Marcel Kinard
>>>> <<>>
>>>> wrote:
>>>>> Is the expected duration 1 hour or 2 hours?
>>>>> On Oct 8, 2014, at 10:56 AM, Michal Mocny <<mailto:
>>>> wrote:
>>>>>> So it looks like Today 1-3 EST or Friday 1-3 EST are the best times.
>>>>> I'm
>>>>>> going to start the ball rolling to do this TODAY, but if that
>>>>>> proves
>>>>> too
>>>>>> short notices we'll move it to Friday.
>>>>>> I'll email out links to hangout at 12:30 or so, and I'm hoping
>>>>>> Steven
>>>>> can
>>>>>> make it before 2pm since he's been most active with releases
>> recently.
>>>>>> -Michal

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message