cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Plugin / Platform mismatch problems
Date Fri, 26 Jul 2013 17:27:08 GMT
I think XML is not a query friendly language. I suggest we add an
engine field initially and then add fields as we need them. I suspect
we won't be needing the bulk of plugin.xml in the registry. I have to
experiment with custom fields still but it seems possible. I will
report back sometime today.

On Fri, Jul 26, 2013 at 9:23 AM, Filip Maj <fil@adobe.com> wrote:
> I think this was brought up before, but why not store the plugin xml in
> its entirety? I can us needing more bits down the road, such as
> dependencies and platform version requirements.
>
>
> On 7/26/13 7:32 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:
>
>>That all sounds good, but let's talk more about the git ref part:
>>
>>It looks like our npm-based directory system is going to host the .tgz of
>>the plugins, so it won't matter what git ref the .tgz maps back to unless
>>we think that a lot of people are not going to use our directory service.
>>
>>One thing that would be useful though, is a way to list plugins compatible
>>with your version of cordova (e.g. query for the latest version of
>>cordova-plugin-file that is compatible with 3.0.0). I think all that's
>>required here is to store the engine tag in the couchdb metadata alongside
>>the tgz.
>>
>>
>>On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes <benn.mapes@gmail.com> wrote:
>>
>>> +1 to brett's comments.
>>> Name - Human Readable name of the plugin to be used in the context of
>>>  plugin
>>> discovery.
>>> ID - unique id used by tools to reference the plugin
>>> Description - sentence+ about the plugin (optional?)
>>>
>>> As for how plugins should be loaded I liked Braden's suggestion that
>>>plugin
>>> authors decide what the default ref is for their plugin. Default should
>>>be
>>> master if no ref is provided.
>>>
>>>
>>> On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill <stevengill97@gmail.com>
>>> wrote:
>>>
>>> > I am going to hold off on testing + deploying+ merging this back in
>>>until
>>> > we get some sort of consensus on naming
>>> >
>>> >
>>> > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett <brettrudd@gmail.com>
>>> wrote:
>>> >
>>> > > name is human readable and should be retained for plugin discovery
>>> tools
>>> > > etc. (such as build.phonegap.com)
>>> > >
>>> > > in the wild, i find description is anything from a sentence to a
>>>small
>>> > > paragraph, so a smaller human readable field as a name is valuable.
>>> > >
>>> > > as for using id instead of name for plugman, i transfer my voting
>>>power
>>> > to
>>> > > anis.
>>> > >
>>> > > -brett
>>> > >
>>> > > On 25 Jul 2013, at 11:59, Shazron <shazron@gmail.com> wrote:
>>> > >
>>> > > > Maybe "name" is the "human" readable name as opposed to id which
>>>is
>>> for
>>> > > > tools
>>> > > >
>>> > > >
>>> > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve <
>>> agrieve@chromium.org
>>> > > >wrote:
>>> > > >
>>> > > >> Anis - can we make it use id instead? I think that's more
inline
>>> with
>>> > > the
>>> > > >> purpose of the field.
>>> > > >>
>>> > > >> Maybe we should remove the name field? I can't think of a
>>>meaningful
>>> > > >> distinction between name and id given that we already have
a
>>> > description
>>> > > >> field.
>>> > > >>
>>> > > >>
>>> > > >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill <
>>> stevengill97@gmail.com>
>>> > > >> wrote:
>>> > > >>
>>> > > >>> Thanks for the advice Shaz and Andrew.
>>> > > >>>
>>> > > >>> I will make sure to mention the issue in the commit so
the bot
>>> picks
>>> > it
>>> > > >> up.
>>> > > >>>
>>> > > >>> Just talked to Anis and he says it is the name tag and
not the
>>>ID.
>>> I
>>> > > >> could
>>> > > >>> go and rename all of the core plugins to start with 'core-'
if
>>>that
>>> > > makes
>>> > > >>> more sense to people. I like it. Distinguishes core plugins
from
>>> > > >> community
>>> > > >>> ones.
>>> > > >>>
>>> > > >>> I will make sure to do a release bug once ready. Mobile-spec
>>>tests
>>> > for
>>> > > >> sure
>>> > > >>> and I will upload to registry (gotta do it eventually
:P)
>>> > > >>>
>>> > > >>> -Steve
>>> > > >>>
>>> > > >>>
>>> > > >>>
>>> > > >>>
>>> > > >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve <
>>> agrieve@chromium.org
>>> > >
>>> > > >>> wrote:
>>> > > >>>
>>> > > >>>> Steve - If you mention the CB-XXXX in the commit description
>>>then
>>> a
>>> > > bot
>>> > > >>>> will automatically add a comment to the issue with
the commit
>>> link.
>>> > > The
>>> > > >>>> issues aren't very useful if they don't point to the
commits
>>>that
>>> > fix
>>> > > >>> them.
>>> > > >>>>
>>> > > >>>> For the names - just wanted to verify whether it was
the name
>>> field
>>> > or
>>> > > >>> the
>>> > > >>>> id field that can't have caps/spaces? If it's the
name, then ID
>>> > seems
>>> > > a
>>> > > >>> bit
>>> > > >>>> redundant. Either way - I think it's important to
have some
>>>sort
>>> of
>>> > > >>> common
>>> > > >>>> prefix for cordova-core plugins. E.g. core-vibration,
or
>>> > > >>>> org.apache.cordova.vibration.
>>> > > >>>>
>>> > > >>>> I think any merge into master is worthy of a release
bug. That
>>>way
>>> > you
>>> > > >>> can
>>> > > >>>> link it with the commit that bumps the package.json
version.
>>> > Probably
>>> > > >> one
>>> > > >>>> bug for all the plugins being released is fine though.
In the
>>> > release
>>> > > >>> bug,
>>> > > >>>> I think you should state what you tested, mobile-spec
is the
>>>goto,
>>> > but
>>> > > >> in
>>> > > >>>> this case, you may want to say that you tested uploading
to the
>>> > > plugins
>>> > > >>>> registry.
>>> > > >>>>
>>> > > >>>>
>>> > > >>>> On Wed, Jul 24, 2013 at 6:26 PM, Shazron <shazron@gmail.com>
>>> wrote:
>>> > > >>>>
>>> > > >>>>> plugin.xml changes only correct? IMO bump the
version and run
>>>the
>>> > > >> steps
>>> > > >>>>> here to test plugin add:
>>> > > >>> http://wiki.apache.org/cordova/WorkingWithThree
>>> > > >>>>>
>>> > > >>>>>
>>> > > >>>>>
>>> > > >>>>>
>>> > > >>>>> On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill <
>>> > stevengill97@gmail.com
>>> > > >>>
>>> > > >>>>> wrote:
>>> > > >>>>>
>>> > > >>>>>> So I just added a dev branch for all of the
plugins and
>>>finished
>>> > > >> the
>>> > > >>>>> issues
>>> > > >>>>>> [1] [2] [3]. All three of these were minor
fixes and I don't
>>> > > >> believe
>>> > > >>>>>> require retesting all of the plugins on every
platform. What
>>> > should
>>> > > >>> my
>>> > > >>>>> next
>>> > > >>>>>> steps be? I know if I merge into master, I
should bump the
>>> version
>>> > > >>> for
>>> > > >>>>> all
>>> > > >>>>>> of them to 0.1.1. Is this something I should
create a release
>>> bug
>>> > > >> for
>>> > > >>>> and
>>> > > >>>>>> get tested before merging into master?
>>> > > >>>>>>
>>> > > >>>>>>
>>> > > >>>>>> [1] https://issues.apache.org/jira/browse/CB-4371
>>> > > >>>>>> [2] https://issues.apache.org/jira/browse/CB-4370
>>> > > >>>>>> [3] https://issues.apache.org/jira/browse/CB-4338
>>> > > >>>>>>
>>> > > >>>>>>
>>> > > >>>>>> On Mon, Jul 22, 2013 at 12:41 PM, Brian LeRoux
<b@brian.io>
>>> > wrote:
>>> > > >>>>>>
>>> > > >>>>>>> Like that
>>> > > >>>>>>>
>>> > > >>>>>>> On Mon, Jul 22, 2013 at 3:33 PM, Andrew
Grieve <
>>> > > >>> agrieve@chromium.org
>>> > > >>>>>
>>> > > >>>>>>> wrote:
>>> > > >>>>>>>> Oh! Oh! Perhaps have multiple definitions
based on CDV
>>> version.
>>> > > >>>> e.g.:
>>> > > >>>>>>>>
>>> > > >>>>>>>> <engine min-cdv-version="2.8" max-cdv-version="2.8">
>>> > > >>>>>>>>  <default-git-ref>refs/head/2.8.x</default-git-ref>
>>> > > >>>>>>>> </engine>
>>> > > >>>>>>>> <engine min-cdv-version="2.9">
>>> > > >>>>>>>>  <default-git-ref>refs/tags/stable</default-git-ref>
>>> > > >>>>>>>> </engine>
>>> > > >>>>>>>>
>>> > > >>>>>>>>
>>> > > >>>>>>>> Then, when someone plugman installs
the git URL, it can
>>>fetch
>>> > > >> it
>>> > > >>>> and
>>> > > >>>>>>>> checkout a version that best matches
your cordova version.
>>> > > >>>>>>>> Then, when you update your cordova
version, it can go
>>>through
>>> > > >>> your
>>> > > >>>>>>> plugins
>>> > > >>>>>>>> and update them to different branches
(unless you glue
>>>them to
>>> > > >> a
>>> > > >>>> ref
>>> > > >>>>>> as a
>>> > > >>>>>>>> part of your install URL)
>>> > > >>>>>>>>
>>> > > >>>>>>>>
>>> > > >>>>>>>>
>>> > > >>>>>>>> On Mon, Jul 22, 2013 at 2:44 PM, Braden
Shepherdson <
>>> > > >>>>>> braden@chromium.org
>>> > > >>>>>>>> wrote:
>>> > > >>>>>>>>
>>> > > >>>>>>>>> The model I had always imagined
was that we would do
>>> something
>>> > > >>>>> similar
>>> > > >>>>>>> to
>>> > > >>>>>>>>> npm: Plugin authors decide what
the default ref is for
>>>their
>>> > > >>>> plugin.
>>> > > >>>>>>> Could
>>> > > >>>>>>>>> be master, some other branch,
a tag, a hash. That's what
>>>the
>>> > > >>>>> discovery
>>> > > >>>>>>> tool
>>> > > >>>>>>>>> will return when a user asks to
add that plugin without
>>> > > >>> explicitly
>>> > > >>>>>>>>> specifying a version. I think
this is a good idea we
>>>should
>>> > > >>>>> implement
>>> > > >>>>>>> too.
>>> > > >>>>>>>>>
>>> > > >>>>>>>>> Braden
>>> > > >>>>>>>>>
>>> > > >>>>>>>>>
>>> > > >>>>>>>>> On Fri, Jul 19, 2013 at 10:16
AM, Andrew Grieve <
>>> > > >>>>> agrieve@chromium.org
>>> > > >>>>>>>>>> wrote:
>>> > > >>>>>>>>>
>>> > > >>>>>>>>>> I think it's true that:
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> 1. CLI downloads tagged versions
of platforms
>>> > > >>>>>>>>>> 2. Plugman downloads plugins
from "master" branch
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> This means that we can't check
any code into plugin
>>>master
>>> > > >>>>> branches
>>> > > >>>>>>>>> without
>>> > > >>>>>>>>>> them going live immediately.
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> Best solution would be to
change plugman to download
>>>from a
>>> > > >>> tag
>>> > > >>>> by
>>> > > >>>>>>>>> default,
>>> > > >>>>>>>>>> but a bit late for that now...
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> Instead, I think we should
change all development on
>>> > > >> plugins:
>>> > > >>>>>>>>>> - Commit only to "dev" branch.
>>> > > >>>>>>>>>> - When we want to push an
update, we should file a
>>>release
>>> > > >> bug
>>> > > >>>> for
>>> > > >>>>>> the
>>> > > >>>>>>>>>> plugin, test on all platforms
>>> > > >>>>>>>>>> Case 1: The changes work with
3.0 cordova: then merge
>>>into
>>> > > >>>> master
>>> > > >>>>>>> (only
>>> > > >>>>>>>>> if
>>> > > >>>>>>>>>> it works of course)
>>> > > >>>>>>>>>> Case 2: The changes require
a platform API that hasn't
>>>been
>>> > > >>>>> release
>>> > > >>>>>>> yet:
>>> > > >>>>>>>>>> Wait and release after the
next cordova core release.
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>> Any other ideas?
>>> > > >>>>>>>>>>
>>> > > >>>>>>>>>
>>> > > >>>>>>>
>>> > > >>>>>>
>>> > > >>>>>
>>> > > >>>>
>>> > > >>>
>>> > > >>
>>> > >
>>> > >
>>> >
>>>
>

Mime
View raw message