cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <tere...@tmbsw.com>
Subject Re: Independent platform release summary
Date Thu, 09 Oct 2014 22:09:40 GMT
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 <terence@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 <clantz@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.treggiari@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: mmocny@google.com [mailto:mmocny@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.treggiari@intel.com
>>>> <mailto:leo.treggiari@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: mmocny@google.com<mailto:mmocny@google.com> [mailto:
>>>> mmocny@google.com<mailto:mmocny@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 <mmocny@chromium.org
>>>> <mailto:
>>>> mmocny@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 <mmocny@chromium.org
>>>>>
>>>> <mailto:mmocny@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
>>>>>> <cmarcelk@gmail.com<mailto:cmarcelk@gmail.com>>
>>>>>> wrote:
>>>>>>
>>>>>>   Is the expected duration 1 hour or 2 hours?
>>>>>>> On Oct 8, 2014, at 10:56 AM, Michal Mocny <mmocny@chromium.org
>>>>>>> <mailto:
>>>>>>>
>>>>>> mmocny@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-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message