cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benn Mapes <benn.ma...@gmail.com>
Subject Re: Plugin / Platform mismatch problems
Date Thu, 25 Jul 2013 22:38:26 GMT
+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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message