ssage-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
Andrew
Grieve
Sent: Thursday, July 24, 2014 6:47 AM
To: dev
Subject: Re: Proposal: remove platform versions from platfroms.js
I agree that the feature will make installing platforms less
predictable...
or at least, j
> > > > > > > > of different versions over time. The CLI would need to be
> > > validated
> > > > > > > across
> > > > > > > > a number of different major and minor versions which
> increases
> > > the
> > >
> >
> > > > > > 1. Install a platform (say, android 3.2)
> > > > > > 2. Update CLI to 3.5.0
> > > > > > 3. CLI now expected to work with version of platform you have
> > > > installed.
> > > > > > 4. Decide you want to updat
tforms less
> > > > > predictable...
> > > > > > or at least, just as unpredictable as plugins.
> > > > > >
> > > > > > It is a good idea to look at exactly what the benefits are
> though.
> > > > > >
> > > > > >
> > all platforms will update with one version change. I think that is
> > the
> > > > > issue with platforms - There needs to be a mechanism to communicate
> > > that
> > > > > something has changed across multiple platforms.
> > > > >
> &g
plugin drops support for android-3.0.0, then
> > > users are free to stick with an older version of the plugin that does
> > > support it. I do conceded that our tooling is currently not great about
> > > making this easy to do though.
> > >
> >
not all platforms even have
> people
> > actively working on them. What's the gain in trying to synchronize them?
> It
> > would only cause things to be released more slowly.
> >
> > For example, we recently had icons and splashscreen support added to CLI
> >
t;
> For example, we recently had icons and splashscreen support added to CLI
> for some but not all platforms. This actually required no changes in
> platforms, because platforms already supported both. This is a great
> example of why we'd want CLI to not be pinned to platform ver
t keep rolling forwards. Predictably!
> >
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Wed, Jul 23, 2014 at 10:59 AM, Parashuram Narasimhan (MS OPEN TECH)
> > < panar...@microsoft.com> wrote:
> >
> > > I was thi
ass on to end users.
-Chuck
-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Thursday, July 24, 2014 6:47 AM
To: dev
Subject: Re: Proposal: remove platform versions from platfroms.js
I agree that the feature will make installing platforms l
-Original Message-
> > From: Anis KADRI [mailto:anis.ka...@gmail.com]
> > Sent: Wednesday, July 23, 2014 10:54 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Proposal: remove platform versions from platfroms.js
> >
> > +1 for package.json for platforms.
If you're interested in this I think it'd be best to look at the
--experimental "plugin save" and "plugin restore" commands and try to
iterate from there.
On Wed, Jul 23, 2014 at 5:21 PM, Carlos Santana
wrote:
> +1 on removing the pining
>
> Can we at least record what's get's installed in a si
android@3.5.1"?
>
Hmm, "platform add android@3.5.0" works fine using CLI@master. @3.5.1
wouldn't work because there is no 3.5.1 yet.
>
> -Chuck
>
> -Original Message-
> From: Carlos Santana [mailto:csantan...@gmail.com]
> Sent: Wednesday, July
eased faster. However, I not see
that 3.5.0-0.2.6 was allowing you to do "platform add android@3.5.1"?
-Chuck
-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com]
Sent: Wednesday, July 23, 2014 2:27 PM
To: dev@cordova.apache.org
Subject: Re: Proposal: remove p
I forgot to mention but agree with suggestion of having a local version of
cordova cli saved in node_modues, and that the default cordova behavior
will be to look first in local node_modules for cordova cli and if it found
use that one, if not then use global one. same as grunt-cli
On Wed, Jul 2
+1 on removing the pining
Can we at least record what's get's installed in a single place?
This will help if someone is trying to debug a problem, it will be easy to
tell what are the components and their levels being use.
Meaning a the minimum recording platforms, plugins, and latest cli version
I think Mark summarizes my thoughts as well.
We're overdue brainstorming what we want cordova workspaces to look like
(package.json, app manifests / config files, grunt/gulp integration,
browserify, directory structure..). I don't think even the full hour on
this weeks hangout would suffice for t
Part of the discussion is release flexibility vs predictability. My main
problem is that currently we have neither. By default CLI downloads pinned
versions of platforms but latest versions of plugins.
Changing the concept of corodva project to something managed by npm is an
interesting idea but i
dev@cordova.apache.org
> Subject: Re: Proposal: remove platform versions from platfroms.js
>
> +1 for package.json for platforms. plugins might a bit trickier but
> +still
> doable, we could get rid of plugins/ but we somehow need to keep track of
> them in node_modules/ (maybe use
10:47 AM
To: dev@cordova.apache.org
Subject: Re: Proposal: remove platform versions from platfroms.js
Yeah, let's discuss the full impact on Friday.
@purplecabbage
risingj.com
On Wed, Jul 23, 2014 at 7:36 AM, Michal Mocny wrote:
> This sounds like a great topic for hangout Friday.
: Wednesday, July 23, 2014 10:54 AM
To: dev@cordova.apache.org
Subject: Re: Proposal: remove platform versions from platfroms.js
+1 for package.json for platforms. plugins might a bit trickier but
+still
doable, we could get rid of plugins/ but we somehow need to keep track of them
in node_modules
+1 for package.json for platforms. plugins might a bit trickier but still
doable, we could get rid of plugins/ but we somehow need to keep track of
them in node_modules/ (maybe use one of the 10 config files we have).
Platforms in package.json should cause no problems though, add/remove
platforms,
Yeah, let's discuss the full impact on Friday.
@purplecabbage
risingj.com
On Wed, Jul 23, 2014 at 7:36 AM, Michal Mocny wrote:
> This sounds like a great topic for hangout Friday. Glad to have a concrete
> proposal / some counter arguments to discuss.
>
>
> On Wed, Jul 23, 2014 at 10:22 AM, M
This sounds like a great topic for hangout Friday. Glad to have a concrete
proposal / some counter arguments to discuss.
On Wed, Jul 23, 2014 at 10:22 AM, Mark Koudritsky wrote:
> >
> > Currently WebWorks ships specific versions of things.
> > If we had shipped unpinned versions of stuff, then
>
> Currently WebWorks ships specific versions of things.
> If we had shipped unpinned versions of stuff, then eventually we would
> have created projects which our UI wouldn't have recognized as valid
> (because, they e.g. Didn't have a ".cordova", or a "hooks", or a "merges"
> or whichever things
Josh Soref [mailto:jso...@blackberry.com]
> Sent: Tuesday, July 22, 2014 3:06 PM
> To: dev@cordova.apache.org
> Subject: Re: Proposal: remove platform versions from platfroms.js
>
> Mark Koudritsky wrote:
> >As the next step in decoupling platform releases I would like to remove
>
ubject: Re: Proposal: remove platform versions from platfroms.js
Mark Koudritsky wrote:
>As the next step in decoupling platform releases I would like to remove
>the hard-coded version in platform.js and let the CLI to download the
>latest platform version available on npm by defau
Mark Koudritsky wrote:
>As the next step in decoupling platform releases I would like to remove
>the
>hard-coded version in platform.js and let the CLI to download the latest
>platform version available on npm by default.
As long as the file will continue to support pinned versions…
I'm not quite
28 matches
Mail list logo
