> Ahh.. the stages of config.xml discussions. Starts with "rename things" > continues to "rename more" and usually ends with "let's change to JSON" > :)
How boring would life be without constantly renaming things to give the impression of progress? :) > It looks like single attribute is preferred, so instead of trying to > find a word that can mean "source and version", we should settle on > version and change it for plugin. I could live with that, however I have one final suggestion which personally I'd much prefer (because I still cringe when I see the "version" attribute with a filename or URL as its value)... I won't cry myself to sleep if I can't get agreement on it, but I think it is where I'd cast my vote... Npm internally uses the term "spec" for this value, and I think that works pretty well - it's general enough to cover both scenarios, while conveying the right sense: <engine name="windows" spec="https://github.com/apache/cordova-windows/tarball/master"; /> <engine name="windows" spec="^1.2.3" /> Tim ________________________________________ From: Gorkem Ercan [gorkem.er...@gmail.com] Sent: Wednesday, April 01, 2015 3:59 AM To: dev@cordova.apache.org Subject: Re: Question about plugin/platform --save: src vs version? On 31 Mar 2015, at 8:44, Tim Barham wrote: > So... I agree that: > > a) if we don't find it in the specified location, we should fail, and > b) storing the version is really superfluous when a source location is > specified (since we're gonna grab whatever is at the specified > location regardless of version). > > And particularly since one of our goals with this was to move towards > being more npm'ish - 'npm install' doesn't save the version when you > specify a source location. For example: > > "dependencies": { > "semver": "https://github.com/npm/node-semver/tarball/master"; > } > > Jesse - are you suggesting that rather than having a name and a > ?version attribute, we instead store them in a single attribute, > something like the following? > > <engine param="windows@^1.2.3" /> > <engine param="windows@http://myplatforms/cordova-windows.tgz"; /> > > (I'm not actually suggesting "param" BTW - just something for the sake > of example) > > That's a possibility, though it makes it harder to quickly look up > something by name (that is, simply find the element that has a 'name' > attribute that matches). So I'd prefer to keep the name ad the other > bit in separate attributes, but use the same attribute name whether > we're storing version or source. That, we go with: > > <engine name="windows" > xxx="https://github.com/apache/cordova-windows/tarball/master"; /> > <engine name="windows" xxx="^1.2.3" /> > > But where "xxx" is something other than "version" or "src" (something > that works for both types of value). Any suggestions? Only thing that > comes to my mind right now is "at" (because of the "@"): > > <engine name="windows" > at="https://github.com/apache/cordova-windows/tarball/master"; /> > <engine name="windows" at="^1.2.3" /> > > Any better ideas? Ahh.. the stages of config.xml discussions. Starts with "rename things" continues to "rename more" and usually ends with "let's change to JSON" :) It looks like single attribute is preferred, so instead of trying to find a word that can mean "source and version", we should settle on version and change it for plugin. > > Thanks! > > Tim > > ________________________________________ > From: Jesse [purplecabb...@gmail.com] > Sent: Tuesday, March 31, 2015 3:53 PM > To: dev@cordova.apache.org > Subject: Re: Question about plugin/platform --save: src vs version? > > I agree with Andrew, fail loudly if we cannot find it. > And, jam all this into 1 attribute which may or may not have a version > ( or > a tag? ) > Essentially just store whatever the parameter to 'cordova plugin add' > was. > > > > > > > @purplecabbage > risingj.com > > On Mon, Mar 30, 2015 at 5:36 PM, Andrew Grieve <agri...@chromium.org> > wrote: > >> I don't think we'd want to try a fallback in this case. Better to >> fail >> loudly if the plugin can't be found where it's expected to be. >> >> I think since NPM uses only a single field (although theirs isn't >> labeled), >> we should do likewise. Don't feel strongly about it though. >> >> On Mon, Mar 30, 2015 at 4:04 PM, Edna Y Morales <eymor...@us.ibm.com> >> wrote: >> >>> It could make sense to store both for the case where restoring from >>> src >>> fails. For example, if the path to a local folder no longer exists, >>> what >> do >>> you use to restore? In that case you could use the version as a >>> fallback? >>> >>> Thanks, >>> Edna Morales >>> >>> [image: Inactive hide details for "Gorkem Ercan" ---03/30/2015 >>> 10:45:03 >>> AM--- On 29 Mar 2015, at 23:11, Tim Barham wrote:]"Gorkem Ercan" >>> ---03/30/2015 10:45:03 AM--- On 29 Mar 2015, at 23:11, Tim Barham >> wrote: >>> >>> From: "Gorkem Ercan" <gorkem.er...@gmail.com> >>> To: "dev [dev@cordova.apache.org]" <dev@cordova.apache.org> >>> Date: 03/30/2015 10:45 AM >>> Subject: Re: Question about plugin/platform --save: src vs version? >>> ------------------------------ >>> >>> >>> >>> >>> >>> On 29 Mar 2015, at 23:11, Tim Barham wrote: >>> >>>> Hi - I'm looking for input on this issue: For the plugin/platform >>>> --save feature, there's currently an inconsistency between how we >>>> store the information in config.xml for platforms vs plugins. >>>> >>>> >>>> >>>> For platforms, we have a 'version' attribute where we store either >>>> the >>>> source location or the version: if the platform was added by >>>> specifying a specific location (git repository, local folder, >>>> package >>>> file etc), we store that in the 'version' attribute. Otherwise we >>>> store the actual version. >>>> >>>> >>>> >>>> For plugins, these two values are stored separately - source >>>> location >>>> in the 'src' attribute and version in the 'version' attribute. Note >>>> however that when we restore a plugin, we ignore the 'version' >>>> attribute if there is a 'src' attribute. >>>> >>>> >>> This comes from the history of the implementation ( as these things >>> do). >>> In the old experimental save implementation, we had 3 parameters, >>> namely, version, url and installPath, and for every plugin we >>> expected >>> one of them to exist. During the effort for npmizing the save >>> functionality the contribution for platforms and plugins were done >>> separately hence the unmatching attributes. So there is no real >>> technical reason for doing one way or the other and if you are >>> willing >>> to unify them that is fantastic. >>> >>> >>>> >>>> I'd like to make these consistent. My first thought was to support >>>> 'version' and 'src' for platforms like we currently do for plugins. >>>> But since we always ignore the version if we have a src, I'm not >>>> sure >>>> we actually gain anything by doing that. Storing them in different >>>> attributes is perhaps clearer, but storing both implies we make use >>>> of >>>> both, which we don't. Also, the code ends up being simpler overall >>>> if >>>> we just store whichever we care about in the version attribute. >>>> >>> >>> I personally prefer to clearly label data in case user needs to >>> read/modify the config.xml, seeing a git url on the version >>> attribute >>> still puzzles me. But I am fine with either way. Whatever you decide >>> please remember to support/migrate the current attributes so that we >>> do >>> not end up with stale entries on config.xml >>> >>>> >>>> >>>> Any thoughts either way? >>>> >>>> >>>> >>>> Thanks! >>>> >>>> >>>> >>>> Tim >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> For additional commands, e-mail: dev-h...@cordova.apache.org >>> >>> >>> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
