cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Independent platform release summary
Date Thu, 09 Oct 2014 21:29:57 GMT
We're not going backwards. What happens when we hit 3.0.0, an already
re-leased version?

On Thu, Oct 9, 2014 at 2:27 PM, 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
>
>

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