+1 for platforms in package.json
On Tue, Apr 8, 2014 at 3:22 PM, Tommy Williams <to...@devgeeks.org> wrote: > +1 for reapproach > On 09/04/2014 8:20 am, "Brian LeRoux" <b...@brian.io> 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" <agri...@chromium.org> wrote: > > > > > On Tue, Apr 8, 2014 at 9:44 AM, Michal Mocny <mmo...@chromium.org> > > wrote: > > > > > > > On Tue, Apr 8, 2014 at 1:32 PM, Andrew Grieve <agri...@chromium.org> > > > > wrote: > > > > > > > > > On Tue, Apr 8, 2014 at 3:30 AM, Gorkem Ercan < > gorkem.er...@gmail.com > > > > > > > > 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 < > mmo...@chromium.org> > > > > > wrote: > > > > > > > > > > > > > On Mon, Apr 7, 2014 at 7:56 PM, Shazron <shaz...@gmail.com> > > 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 < > > > > gorkem.er...@gmail.com > > > > > > > > > > > > > > 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 <b...@brian.io> > > > 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: > > > > > > > > > > > > > > > > > > > > CLI@X.X.X > > > > > > > > > > '- cordova@X.X.X > > > > > > > > > > |-ios@X.X.X > > > > > > > > > > '-android@X.X.X > > > > > > > > > > > > > > > > > > > > This is how it would work in the new world order: > > > > > > > > > > > > > > > > > > > > CLI@X.X.X > > > > > > > > > > |- ios@X.X.X > > > > > > > > > > '-android@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 < > > > > > cmarc...@gmail.com > > > > > > > > > > > > > > > > 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 < > > > > > gorkem.er...@gmail.com > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
