Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of purplecabbage@gmail.com
 designates 209.85.214.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1428330522948.38732@microsoft.com>
References: 
 <A121B9C55062F74383A10254CBA1DB6F295A5666@SINPRD3002MB008.064d.mgd.msft.net>
	<87D960E7-4D04-4461-8BD6-057F6505AB13@gmail.com>
	<OFCE16072A.F3813D06-ON85257E18.006DA48C-85257E18.006E48C3@us.ibm.com>
	<CABiQX1Vnyk8BckdcoRQHa0nPNsyt7g4O0B7S=BRCPD_KwjORKg@mail.gmail.com>
	<CAKP6k2uZDAjYDd7KBRz1qRhwxchB8KXjW=r-aD29dO+n4eiBjA@mail.gmail.com>
	<A121B9C55062F74383A10254CBA1DB6F295B4EE1@SINPRD3002MB008.064d.mgd.msft.net>
	<36B80F86-DA4A-4E75-AB31-012FBE3549F7@gmail.com>
	<A121B9C55062F74383A10254CBA1DB6F295C244F@SINPRD3002MB008.064d.mgd.msft.net>
	<CAKP6k2ttjG+__cC6CfM-rpoQdNB8Fnq_qtA10xJtsP7HuruYfw@mail.gmail.com>
	<1428330522948.38732@microsoft.com>
Date: Mon, 6 Apr 2015 11:28:07 -0700
Message-ID: 
 <CAKP6k2v5=OF3KE7fsi+g9BehqpYukE=zepgVZgrE2TvCiB_C1Q@mail.gmail.com>
Subject: Re: Question about plugin/platform --save: src vs version?
From: Jesse <purplecabbage@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a1130d2faa961c6051312750a

--001a1130d2faa961c6051312750a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 versio=
n.
> I think that has the potential to get confusing quickly. Anyway, primaril=
y
> 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=3D"^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 "versio=
n"
> 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, whi=
le
> conveying the right sense:
> >
> > <engine name=3D"windows" spec=3D"
> https://github.com/apache/cordova-windows/tarball/master" />
> > <engine name=3D"windows" spec=3D"^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=3D"windows@^1.2.3"  />
> >> <engine param=3D"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=3D"windows"
> >> xxx=3D"https://github.com/apache/cordova-windows/tarball/master" />
> >> <engine name=3D"windows" xxx=3D"^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=3D"windows"
> >> at=3D"https://github.com/apache/cordova-windows/tarball/master" />
> >> <engine name=3D"windows" at=3D"^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 =E2=80=8E[dev@cordova.apache.org]=E2=80=8E" <dev@cordova.ap=
ache.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
>
>

--001a1130d2faa961c6051312750a--