I'm ok with 'spec' However; I had always thought we would jam the new single attribute into 'src' which is much more generic than 'version', and I think is still close enough in meaning.
I have been looking at this more from the perspective of added plugins, but I think even the engine tag having a src="^1.2.3" makes sense. It just means it comes from the 'default' location, at that particular version. On Apr 1, 2015, at 6:43 AM, Tim Barham <tim.bar...@microsoft.com> wrote: >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
