cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Plugin / Platform mismatch problems
Date Fri, 26 Jul 2013 16:23:06 GMT
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