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 Kinard <[email protected]> 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 <[email protected]> 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 > >
