cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Treggiari, Leo" <>
Subject RE: Independent platform release summary
Date Fri, 10 Oct 2014 17:06:40 GMT
Thanks for the answers and they make sense to me.  Just a couple of follow-ons – see [LEO]

From: [] On Behalf Of Michal Mocny
Sent: Friday, October 10, 2014 9:54 AM
To: Treggiari, Leo
Cc: Michal Mocny; Marcel Kinard; dev
Subject: Re: Independent platform release summary

On Thu, Oct 9, 2014 at 3:22 PM, Treggiari, Leo <<>>
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?
"The Cordova Release" can be labelled with the CLI version number.  That number just doesn't
make sense to apply to all platforms, and is harmful to some of our goals.
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
Okay, great question.  Heres how I think that would play out:

First, we add this new config.xml feature to the CLI.  We document this in the CLI documentation,
and should be obvious which CLI versions to support this feature.
[LEO]  Will this happen before the “big change”?  It would be nice if it did.

If this feature also required platform changes:
- Ideally, we implement the CLI change in a way that just warns when the platform is too old,
and no-ops if so.  This is actually historically common (minus the warnings!).
- If that isn't possible, and the change will actually break existing platforms, that means
the CLI has to do a MAJOR revision bump.
- Platforms have <engine> tags to say they expect a particular CLI version >= x.y.z
and < (x+1).0.0, and so updates to CLI that are MAJOR require updates to all platforms.
- You can downgrade your CLI, perhaps only locally using local node_module installs, should
you want to avoid this situation in an old project.
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.
As discussed, we would split CLI/platform docs and version alongside releases (like plugins).
 In this case, you would probably be reading the CLI docs for config.xml settings, and can
follow a link to platform-specific extensions.
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?

Few questions here..
Yes, plugins are not pinned in any way, they always install latest.
Yes, platforms are pinned, in that there is a pre-selected default version that will be installed
which is tied to the CLI version.
Yes, there are ways to explicitly override the default version of platform / plugin that gets
Yes, when you update CLI on npm, you "pinnings" change, but no platforms are actually upgraded
anywhere.  You don't even download the platforms at this point, it just affects the next time
you "platform add" somewhere.
[LEO]  I get the last distinction (npm update) now and didn’t before.  That makes sense,
but would be better if it were well documented.  Maybe it is and I just didn’t see it.

Should the plugin and platform ‘pin’ behavior be the same?

Personally, I think so, but this is something we can decide later.  Right now there are already
a lot of changes, and pinning has been what we've done historically.  There was a long thread
about this and there were some good reasons mentioned there for why this should continue for
now (I don't recall them, I can find and forward the thread).
[LEO]  I agree that leaving the pinning behavior as-is for now is the best choice.

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.


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 <<>>
> 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".


-----Original Message-----
From:<> [<>]
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

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?


On Wed, Oct 8, 2014 at 12:35 PM, Michal Mocny <<>>

> External Public link for those that just want to watch/chat:
> Hangout link to join the conversation:
> See you in 30 minutes.
> On Wed, Oct 8, 2014 at 12:33 PM, Michal Mocny <<>>
>> +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 <<>>
>>> > 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message