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 beyond the problems like the one I had. For instance take a moment and try to imagine how one would need to write the same announcement for an independent release. By the way, I keep hearing that independent platform releases has not happened yet but since iOS has a 3.4.1 release while all other platforms are 3.4.0 and CLI is getting ready for a release that picks up iOS 3.4.1 what else is missing for it to happen? [1] https://twitter.com/PhoneGapBuild/status/453271589803405313 -- Gorkem On Mon, Apr 7, 2014 at 7:24 PM, Michal Mocny <[email protected]> wrote: > On Mon, Apr 7, 2014 at 7:56 PM, Shazron <[email protected]> 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 the proposal was, but as Joe says, this hasn't > happened yet and so is still up in the air. > > Strictly speaking, if we chose to version everything with semver, the > version numbers would diverge over time. The specific x.y.z of one > artifact would be meaningless when compared to other artifacts, but in > exchange potentially more useful when compared to other versions of the > same artifact. > > Implicitly, each release happens on a date, and CLI releases on a given > date depend on the latest releases of each platform. So, if you have any > single artifact, you can get the release date, then the corresponding CLI > release, and finally use that to map backwards to specific semver versions > of all platforms. > > Personally, though, I'm not sure that we are using Semver to good effect at > all, and its just hurting us. I'd suggest we consider switching to > versioning by date (aka the Ubuntu / Chromium / etc model). > > > > (android, ios, bb) this would be true I suppose, at least until 3.5.0 > (not > > sure when we are diverging). > > > > Since the CLI is tied to certain platform versions, I don't see why the > map > > can't be auto generated. > > > > > > > > > > On Mon, Apr 7, 2014 at 4:44 PM, 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 > > > > > > > > > > > > > > > > > > > >
