cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: Suggestions for a problem
Date Mon, 07 Apr 2014 23:07:58 GMT
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

'- cordova@X.X.X

This is how it would work in the new world order:

|- ios@X.X.X

This means other tool that depends on the version locked convenience of the
Cordova release basically will want to track whatever we do with the CLI
instead. Convienantly we will having this in the Cordova package.json so,
hypothetically, this is super easy.

On Tue, Apr 8, 2014 at 10:24 AM, Marcel Kinard <> wrote:

> 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
> straightforward. After 3.0, and additionally potentially releasing
> platforms separately, our definition of "a Cordova version" has basically
> fallen apart (separate timing for plugins and tools, non-shrinkwrapped npm
> dependencies, etc)
> Perhaps one way to solve this would be a "Cordova version" identifier that
> is a map to the individual versions of all the components, similar to how
> cordova-cli/platforms.js has a version property for each platform, but
> include tools and even plugins. How often would it make sense to update
> that version-map and bump the Cordova version? There are probably arguments
> for both a cadence schedule as well as anytime-any-component-changes.
> On Apr 7, 2014, at 5: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 all platforms would be tagged and
> released
> > with X.Y.Z. so if Eclipse tools needed to download Cordova version X.Y.Z,
> > it could just do so by using the X.Y.Z git tag. Now that platforms can do
> > independent releases the X.Y.Z tag for may not exist for a release for a
> > platform. So I actually need a way to determine what platform versions go
> > together. CLI actually captures that information on platforms.js for the
> > release but this is not enough for Eclipse tools as it does not capture
> the
> > data for older releases and Eclipse tools can be download and use older
> > versions.
> >
> > Is there a place where I can extract this sort of platform version
> > information?
> > Also in the past, plugins could define engine compatibility as below
> > <engine name="cordova" version="1.7.0" />
> > How does plugman act with the independent releases now?
> > --
> > Gorkem

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