cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parashuram Narasimhan (MS OPEN TECH)" <panar...@microsoft.com>
Subject Re: Independent platform release summary
Date Thu, 09 Oct 2014 22:49:00 GMT
I meant tag and start the vote for the next release :)

On 10/9/14, 3:01 PM, "Chuck Lantz" <clantz@microsoft.com> wrote:

>+1
>
>-Chuck
>
>-----Original Message-----
>From: Jesse [mailto:purplecabbage@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 <stevengill97@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) <
>> panarasi@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" <clantz@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:stevengill97@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 <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_23HiTl
>> > >> > 4I 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
>> >
>> >
>>
>?B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�
>?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?�ܙ?ݘK�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�
>?�??K[XZ[?�??]�Z?[???�ܙ?ݘK�\?X�?K�ܙ�B

Mime
View raw message