cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: Independent platform release summary
Date Thu, 09 Oct 2014 21:52:18 GMT
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
>
>

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