I'm okay with spec, the pr looks good. Are there any side-effects updating the version of sem-ver?
@purplecabbage risingj.com On Mon, Apr 6, 2015 at 7:28 AM, Tim Barham <tim.bar...@microsoft.com> wrote: > Ok, so... Jesse's ok with 'spec', but prefers 'src'. Gorkem prefers > 'version'. Glad we at least agree we need something :). > > So, because I'd like to wrap this up and get this change in (in part > because along with this specific change I have a couple of fixes for > platform - save the version that was actually installed, and save it as a > tilde range), I've coded up all three. > > When working on this, one benefit I found with using 'spec' was that I > think it makes the code clearer. That is, we have this value 'spec' that > can be a version or a source location, rather than a value 'version' that > actually might not be a version, or 'src' that actually might be a version. > I think that has the potential to get confusing quickly. Anyway, primarily > as a result of that, I created the PR for the change with the 'spec' > attribute [1]. But I also have branches for the 'version' [2] and 'src' [3] > attributes. > > Note that for clarity I've renamed variables as appropriate in the places > where I'm making the immediate change (version --> spec or src, for > example), but to keep the change as simple as possible, I haven't renamed > various secondary locations that get called by this code (like lazy_load, > for example). > > [1] https://github.com/apache/cordova-lib/pull/202 > [2] > https://github.com/apache/cordova-lib/compare/master...MSOpenTech:CB-8799-version > [3] > https://github.com/apache/cordova-lib/compare/master...MSOpenTech:CB-8799-src > > Thanks, > > Tim > > ________________________________________ > From: Jesse <purplecabb...@gmail.com> > Sent: Thursday, April 2, 2015 7:01 AM > To: dev@cordova.apache.org > Subject: Re: Question about plugin/platform --save: src vs version? > > 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
