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