cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parashuram Narasimhan (MS OPEN TECH)" <>
Subject Re: Independent platform release summary
Date Thu, 09 Oct 2014 21:45:35 GMT
Lets start with a vote for 10.0.0 ? And if someone feels strongly about
calling it something the vote could be cancelled !!

On 10/9/14, 2:41 PM, "Chuck Lantz" <> wrote:

>Yeah agreed - Vladimir squashed the bug and what was at once point to be
>called 3.7.0 has been mainly waiting on a version number.  Personally I
>am fine with 10.0.0 or 5.0.0 - Either send the message that platform
>versions are divorced from the CLI from a versioning perspective (though
>behavior is still predictable).  Leo - I think at least out of the gate
>devs will likely focus on the CLI version as primary.  Basically today,
>the cadence version of the CLI is what people talk about.  Heck, Cordova
>3.4.1 was 3.4.0 for all platforms but iOS.  The main message is that when
>you platform add android, you may see an npm pull for
>cordova-android@4.3.2 and that is expected.  It's just formalizing the
>message and allows independent platform rev'ing.
>-----Original Message-----
>From: Steven Gill []
>Sent: Thursday, October 9, 2014 2:13 PM
>Cc: Michal Mocny; Marcel Kinard
>Subject: Re: Independent platform release summary
>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
>> 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
>>>> wrote:
>> > External Public link for those that just want to watch/chat:
>> >
>> >
>> > Hangout link to join the conversation:
>> >
>> > 4I 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
>>>> wrote:
>> >>>
>> >>> > So it looks like Today 1-3 EST or Friday 1-3 EST are the best
>> >>> 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:

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

View raw message