I am against it. Its not going to achieve the goal of alleviating
confusion. People see the CLI as the version not the platforms. I'd rather
we went to 5 if anything.
On Oct 9, 2014 3:56 PM, "Parashuram Narasimhan (MS OPEN TECH)" <
panar...@microsoft.com> wrote:

> I meant tag and start the vote for the next release :)
>
> On 10/9/14, 3:01 PM, "Chuck Lantz" <cla...@microsoft.com> wrote:
>
> >+1
> >
> >-Chuck
> >
> >-----Original Message-----
> >From: Jesse [mailto:purplecabb...@gmail.com]
> >Sent: Thursday, October 9, 2014 2:55 PM
> >To: dev@cordova.apache.org
> >Subject: Re: Independent platform release summary
> >
> >+1 to not voting ;) , it implies we will wait 72 hours before moving on.
> >
> >How about if anyone is completely against 10.0.0 they voice it here, in
> >the next couple hours, otherwise we move forward.
> >
> >@purplecabbage
> >risingj.com
> >
> >On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill <stevengil...@gmail.com>
> >wrote:
> >
> >> I don't think a vote is necessary. I'd hate to see us resort to voting
> >> to solve problems. Voting should be a last resort if consensus is
> >> split. I don't see that in this scenario.
> >>
> >> I propose we bumb the version up to 10.0.0.
> >>
> >> On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) <
> >> panar...@microsoft.com> wrote:
> >>
> >> > 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
> >> >
> >> >
> >>
> >?B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�
> >?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?�ܙ?ݘK�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�
> >?�??K[XZ[?�??]�Z?[???�ܙ?ݘK�\?X�?K�ܙ�B
>
>

Reply via email to