You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Tim Barham <Ti...@microsoft.com> on 2015/04/01 15:43:07 UTC
RE: Question about plugin/platform --save: src vs version?
> 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.ercan@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 [purplecabbage@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 <ag...@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 <ey...@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" <go...@gmail.com>
>>> To: "dev [dev@cordova.apache.org]" <de...@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-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Question about plugin/platform --save: src vs version?
Posted by Gorkem Ercan <go...@gmail.com>.
I am OK with spec.
I plan to review #202 today.
--
Gorkem
On 8 Apr 2015, at 5:12, Tim Barham wrote:
> @gorkem - are you ok for this to be merged, or do you feel strongly we
> should stick with 'version'?
>
> Thanks,
>
> Tim
> ________________________________________
> From: Tim Barham <Ti...@microsoft.com>
> Sent: Tuesday, April 7, 2015 8:18 AM
> To: dev@cordova.apache.org
> Subject: Re: Question about plugin/platform --save: src vs version?
>
> Thanks Jesse.
>
> Well, according to semver standards, a bumped minor version means it
> is 100% backwards compatible, and I'm hoping semver at least complies
> with semver standards :). But I did look through all our uses of
> semver and everything seemed pretty basic - nothing to raise a concern
> with a minor version change.
>
> ________________________________________
> From: Jesse <pu...@gmail.com>
> Sent: Tuesday, April 7, 2015 4:28 AM
> To: dev@cordova.apache.org
> Subject: Re: Question about plugin/platform --save: src vs version?
>
> 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 <Ti...@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 <pu...@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 <Ti...@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.ercan@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 [purplecabbage@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
>>>> <ag...@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
>>>>> <ey...@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" <go...@gmail.com>
>>>>>> To: "dev [dev@cordova.apache.org]" <de...@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-unsubscribe@cordova.apache.org
>>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Question about plugin/platform --save: src vs version?
Posted by Tim Barham <Ti...@microsoft.com>.
@gorkem - are you ok for this to be merged, or do you feel strongly we should stick with 'version'?
Thanks,
Tim
________________________________________
From: Tim Barham <Ti...@microsoft.com>
Sent: Tuesday, April 7, 2015 8:18 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?
Thanks Jesse.
Well, according to semver standards, a bumped minor version means it is 100% backwards compatible, and I'm hoping semver at least complies with semver standards :). But I did look through all our uses of semver and everything seemed pretty basic - nothing to raise a concern with a minor version change.
________________________________________
From: Jesse <pu...@gmail.com>
Sent: Tuesday, April 7, 2015 4:28 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?
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 <Ti...@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 <pu...@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 <Ti...@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.ercan@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 [purplecabbage@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 <ag...@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 <ey...@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" <go...@gmail.com>
> >>>> To: "dev [dev@cordova.apache.org]" <de...@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-unsubscribe@cordova.apache.org
> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Question about plugin/platform --save: src vs version?
Posted by Tim Barham <Ti...@microsoft.com>.
Thanks Jesse.
Well, according to semver standards, a bumped minor version means it is 100% backwards compatible, and I'm hoping semver at least complies with semver standards :). But I did look through all our uses of semver and everything seemed pretty basic - nothing to raise a concern with a minor version change.
________________________________________
From: Jesse <pu...@gmail.com>
Sent: Tuesday, April 7, 2015 4:28 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?
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 <Ti...@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 <pu...@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 <Ti...@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.ercan@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 [purplecabbage@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 <ag...@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 <ey...@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" <go...@gmail.com>
> >>>> To: "dev [dev@cordova.apache.org]" <de...@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-unsubscribe@cordova.apache.org
> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Question about plugin/platform --save: src vs version?
Posted by Jesse <pu...@gmail.com>.
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 <Ti...@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 <pu...@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 <Ti...@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.ercan@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 [purplecabbage@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 <ag...@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 <ey...@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" <go...@gmail.com>
> >>>> To: "dev [dev@cordova.apache.org]" <de...@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-unsubscribe@cordova.apache.org
> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Question about plugin/platform --save: src vs version?
Posted by Tim Barham <Ti...@microsoft.com>.
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 <pu...@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 <Ti...@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.ercan@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 [purplecabbage@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 <ag...@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 <ey...@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" <go...@gmail.com>
>>>> To: "dev [dev@cordova.apache.org]" <de...@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-unsubscribe@cordova.apache.org
>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Question about plugin/platform --save: src vs version?
Posted by Jesse <pu...@gmail.com>.
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 <Ti...@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.ercan@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 [purplecabbage@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 <ag...@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 <ey...@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" <go...@gmail.com>
>>>> To: "dev [dev@cordova.apache.org]" <de...@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-unsubscribe@cordova.apache.org
>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org