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 <[email protected]>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 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 LeRoux <[email protected]> wrote: > > > 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: > > > > [email protected] > > '- [email protected] > > |[email protected] > > '[email protected] > > > > This is how it would work in the new world order: > > > > [email protected] > > |- [email protected] > > '[email protected] > > > > 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 <[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 > > > > > > > > >
