Oh, well, scratch that idea. I didn't think about that and wasn't trying to be smart. It's just that you're establishing a new way of looking at and doing things and there needs to be a really clear distinction between CLI and the platforms. Seems very significant to me. Huge even.

-Terence


On 10/9/2014 4:32 PM, Steven Gill wrote:
Unfortunately, that would cause more confusion. I am opposed to lowering
the current version. It would cause havoc once the version worked it's way
back up to 3.



On Thursday, October 9, 2014, Terence M. Bandoian <tere...@tmbsw.com> wrote:

How about 1.0.0 for the CLI version?

-Terence


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 <cla...@microsoft.com> 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.

https://issues.apache.org/jira/browse/CB-7670

-Chuck

-----Original Message-----
From: Treggiari, Leo [mailto:leo.treggi...@intel.com]
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: mmo...@google.com [mailto:mmo...@google.com] 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 <leo.treggi...@intel.com
<mailto:leo.treggi...@intel.com>> 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: mmo...@google.com<mailto:mmo...@google.com> [mailto:
mmo...@google.com<mailto:mmo...@google.com>] 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 <mmo...@chromium.org
<mailto:
mmo...@chromium.org>> wrote:

  External Public link for those that just want to watch/chat:
https://plus.google.com/events/cm4l0vifcig920qkhpn5stqiet4

Hangout link to join the conversation:
https://plus.google.com/hangouts/_/hoaevent/AP36tYcNwXEyet4Xv_23HiTl4I
K0jsM4NlmGy5kbLsPIW3SnOsUEIQ?authuser=0&hl=en

See you in 30 minutes.

On Wed, Oct 8, 2014 at 12:33 PM, Michal Mocny <mmo...@chromium.org

<mailto:mmo...@chromium.org>> 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
<cmarc...@gmail.com<mailto:cmarc...@gmail.com>>
wrote:

  Is the expected duration 1 hour or 2 hours?
On Oct 8, 2014, at 10:56 AM, Michal Mocny <mmo...@chromium.org
<mailto:

mmo...@chromium.org>> 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: 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

Reply via email to