One nice thing about putting them in config.xml, is that we can separate
them from plugins.
e.g.
Again though - with npm's JS api, we don't need a package.json to have npm
do the fetching / caching / version checking for us.
On Wed, Apr 9, 2014 at 6:51 AM, Andrew Grieve wrote:
> The thi
The thing I don't want is platforms in *cli*'s package.json
Introducing a new package.json for each app is something we could consider.
I was just assuming we'd dump it into config.xml instead of creating a new
file. *Either way*, we'd be using npm to do the work.
On Tue, Apr 8, 2014 at 2:41 PM,
+1 for platforms in package.json
On Tue, Apr 8, 2014 at 3:22 PM, Tommy Williams wrote:
> +1 for reapproach
> On 09/04/2014 8:20 am, "Brian LeRoux" wrote:
>
> > Hold up! The CLI needs to declare dependencies somehow and while we could
> > implement our own thing npm will do it better. (Hence th
+1 for reapproach
On 09/04/2014 8:20 am, "Brian LeRoux" wrote:
> Hold up! The CLI needs to declare dependencies somehow and while we could
> implement our own thing npm will do it better. (Hence this thinking.)
>
> But the good news is we can use >=X.X.X in package.json to allow npm to
> download
Hold up! The CLI needs to declare dependencies somehow and while we could
implement our own thing npm will do it better. (Hence this thinking.)
But the good news is we can use >=X.X.X in package.json to allow npm to
download the latest.
Now that said, it would be cool to allow version pinning, mo
On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny wrote:
> On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve
> wrote:
>
> > On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan
> > wrote:
> >
> > > I think a tool can just go through all tagged version of the CLI's
> > > platforms.js and create the version map.
On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve wrote:
> On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan
> wrote:
>
> > I think a tool can just go through all tagged version of the CLI's
> > platforms.js and create the version map. I guess this effectively makes
> CLI
> > versions the Cordova version
On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan wrote:
> I think a tool can just go through all tagged version of the CLI's
> platforms.js and create the version map. I guess this effectively makes CLI
> versions the Cordova version.
>
That's the way I think of it right now as well
>
> I was looki
I think a tool can just go through all tagged version of the CLI's
platforms.js and create the version map. I guess this effectively makes CLI
versions the Cordova version.
I was looking at the phonegap announcement[1], which got me thinking, I
think independent releases may create complications b
On Mon, Apr 7, 2014 at 7:56 PM, Shazron wrote:
> Looks like you will have to generate this yourself for now. But correct me
> if I'm wrong, if the CLI is at version X.Y.Z, wouldn't the platform
> versions be at least X.Y.Z themselves? At least for the main platforms
>
I don't think thats what th
On Mon, Apr 7, 2014 at 8:03 PM, Shazron wrote:
> If needed (looks like it is), we should have a highly specific tool (does
> one thing only) that can generate this map automatically. If the data is
>
Is that a stab at coho? ;)
> lacking to do this automatically, my suggestion is to add this met
If needed (looks like it is), we should have a highly specific tool (does
one thing only) that can generate this map automatically. If the data is
lacking to do this automatically, my suggestion is to add this meta-data to
whatever is lacking (plugins, etc).
On Mon, Apr 7, 2014 at 3:24 PM, Marcel
Looks like you will have to generate this yourself for now. But correct me
if I'm wrong, if the CLI is at version X.Y.Z, wouldn't the platform
versions be at least X.Y.Z themselves? At least for the main platforms
(android, ios, bb) this would be true I suppose, at least until 3.5.0 (not
sure when
package.json does not iterate any historical data but the npm registry can
be queried or, you know, Git can be
On Tue, Apr 8, 2014 at 11:44 AM, Gorkem Ercan wrote:
> Would package.json carry the historical data? At the moment, my plan is to
> have a json file that maps CLI versions to platform v
Would package.json carry the historical data? At the moment, my plan is to
have a json file that maps CLI versions to platform version but for every
version > 3.0.0. It would be great if such a file is updated as part of the
release of CLI though.
--
Gorkem
On Mon, Apr 7, 2014 at 5:07 PM, Brian L
Moving to independent platform releases doesn't change things other than a
mostly arbitrary number we use for issue tracking. This is the way it works
today:
CLI@X.X.X
'- cordova@X.X.X
|-ios@X.X.X
'-android@X.X.X
This is how it would work in the new world order:
CLI@X.X.X
|- ios@X.X.X
'-
The way I would summarize this is that enterprises need a way to recreate a
specific environment. This includes our platforms, plugins, tooling, and
dependencies. Many enterprises do not desire to live on head, instead they want
to live at a known reproductable state. Before 3.0, this was pretty
The plan is to move towards independent releases for platforms.
These are good points Gorkem. Definitely requires more discussion.
On Mon, Apr 7, 2014 at 3:07 PM, Anis KADRI wrote:
> Have we actually decided to move along with the plan? I thought we were
> only discussing it.
>
>
> On Mon, Apr
3.4.1 release exists for only iOS and CLI platforms.js is updated to
accordingly so at least it does feel like it is happening.
--
Gorkem
On Mon, Apr 7, 2014 at 3:07 PM, Anis KADRI wrote:
> Have we actually decided to move along with the plan? I thought we were
> only discussing it.
>
>
> On M
Have we actually decided to move along with the plan? I thought we were
only discussing it.
On Mon, Apr 7, 2014 at 2:04 PM, Joe Bowser wrote:
> We don't know yet because we're still figuring this out.
>
> On Mon, Apr 7, 2014 at 2:00 PM, Gorkem Ercan
> wrote:
> > Hi,
> > With the independent pl
We don't know yet because we're still figuring this out.
On Mon, Apr 7, 2014 at 2:00 PM, Gorkem Ercan wrote:
> Hi,
> With the independent platforms releases I have started to run into a
> problem with my Eclipse tools that I am looking for some suggestions.
>
> In the past, Cordova X.Y.Z meant al
Hi,
With the independent platforms releases I have started to run into a
problem with my Eclipse tools that I am looking for some suggestions.
In the past, Cordova X.Y.Z meant all platforms would be tagged and released
with X.Y.Z. so if Eclipse tools needed to download Cordova version X.Y.Z,
it co
22 matches
Mail list logo
