cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Plugin / Platform mismatch problems
Date Fri, 26 Jul 2013 14:32:41 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message