cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gorkem Ercan" <gorkem.er...@gmail.com>
Subject Re: Question about plugin/platform --save: src vs version?
Date Wed, 08 Apr 2015 16:41:57 GMT

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 <Tim.Barham@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 <purplecabbage@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 <Tim.Barham@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 <purplecabbage@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.Barham@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 
>>>> <agrieve@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 
>>>>> <eymorale@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.ercan@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-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


Mime
View raw message