Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !!
On 10/9/14, 2:41 PM, "Chuck Lantz" <cla...@microsoft.com> wrote: >Yeah agreed - Vladimir squashed the bug and what was at once point to be >called 3.7.0 has been mainly waiting on a version number. Personally I >am fine with 10.0.0 or 5.0.0 - Either send the message that platform >versions are divorced from the CLI from a versioning perspective (though >behavior is still predictable). Leo - I think at least out of the gate >devs will likely focus on the CLI version as primary. Basically today, >the cadence version of the CLI is what people talk about. Heck, Cordova >3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when >you platform add android, you may see an npm pull for >cordova-android@4.3.2 and that is expected. It's just formalizing the >message and allows independent platform rev'ing. > >-Chuck > >-----Original Message----- >From: Steven Gill [mailto:stevengil...@gmail.com] >Sent: Thursday, October 9, 2014 2:13 PM >To: dev@cordova.apache.org >Cc: Michal Mocny; Marcel Kinard >Subject: Re: Independent platform release summary > >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_23HiTl >> > 4I 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
