One nice thing about putting them in config.xml, is that we can separate them from plugins. e.g.
<platform name="android" version="3.4.0"> <plugin name="org...." version="~1.0" /> </platform> 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 <[email protected]> wrote: > 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, Anis KADRI <[email protected]> wrote: > >> +1 for platforms in package.json >> >> >> On Tue, Apr 8, 2014 at 3:22 PM, Tommy Williams <[email protected]> >> wrote: >> >> > +1 for reapproach >> > On 09/04/2014 8:20 am, "Brian LeRoux" <[email protected]> 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 the latest. >> > > >> > > Now that said, it would be cool to allow version pinning, moving away >> > from >> > > config.xml and just using package.json in Cordova projects. This was >> > > brought up a while back but we decided this wasn't a big win. Maybe we >> > can >> > > reapproach. >> > > >> > > >> > > On Apr 9, 2014 6:09 AM, "Andrew Grieve" <[email protected]> wrote: >> > > >> > > > On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny <[email protected]> >> > > wrote: >> > > > >> > > > > On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve < >> [email protected]> >> > > > > wrote: >> > > > > >> > > > > > On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan < >> > [email protected] >> > > > >> > > > > > 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 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? >> > > > > > > >> > > > > > >> > > > > > I think if we get this right, we'd be able to release iOS 3.4.1 >> > > > *without* >> > > > > > having to release a new version of CLI. Just like you don't >> need to >> > > > > update >> > > > > > your version of npm when a new version of cordova-cli comes out. >> > > > > > >> > > > > >> > > > > Does this conflict with the previous statement that tooling >> versions >> > > > match >> > > > > CLI deps? >> > > > > >> > > > >> > > > It does. My hope is that eventually the CLI version won't have any >> > > mapping >> > > > to platform versions. It will just ask npm what the latest version >> is, >> > > and >> > > > use that. If users want to pin their versions, they can do so by >> > > specifying >> > > > the version on the command-line or in their config.xml. >> > > > >> > > > > >> > > > > >> > > > > > >> > > > > > >> > > > > > > >> > > > > > > [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 >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> > >
