Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of benn.mapes@gmail.com designates
 209.85.192.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAMSbhBjitEkq_PVDeY8VLDcB3hJWVwg_u47c1u0VLzT7zy=mkA@mail.gmail.com>
References: 
 <CABiQX1Xm_gNBaG2=jCqo-0H2Cxt=U+VYNGvd26zePJfupfVKOA@mail.gmail.com>
	<CAMk5LLmdXnKUJ73fAwPv7FgBuV6LUX2Jo1TEASkemBhA3t1v-g@mail.gmail.com>
	<CABiQX1VdmKxj88V7sNXH-6oOMDwj-X9kpmYRQJwejzPQ7+wJVA@mail.gmail.com>
	<CADVgkyO02jAbfBX33wbebXU4um-zUbTH2f8CJd2RXOsJ7vJTYw@mail.gmail.com>
	<CAMSbhBjX_98Ea=0JorrB3ZgOaBdbbPfQQEQ-5b4WA2jz=bcVqA@mail.gmail.com>
	<CAE6O_-bRQ5YD6ZWn_Z5eC=sq9dw5-VeATURnZcMtzYNT_QX6aA@mail.gmail.com>
	<CABiQX1WD_wBaMUup639SJ+nAZLZiVuOx4Fkji+wkexAK79_qNQ@mail.gmail.com>
	<CAMSbhBgf87UP=V14jdmi5MXKOYUKST9LcaYny6sg-S7v1zOtwQ@mail.gmail.com>
	<CABiQX1U0smv4CzvObgKVS4t76Fdpj5eWnw_wtaoRifxmRGUtiw@mail.gmail.com>
	<CAE6O_-a6Wz2cThzCGqD-Me5JGmWS-FB_zpHd8Om2_YTuQARvYg@mail.gmail.com>
	<1D23AC66-9455-404B-ACB8-BA66FCE7106D@gmail.com>
	<CAMSbhBjitEkq_PVDeY8VLDcB3hJWVwg_u47c1u0VLzT7zy=mkA@mail.gmail.com>
Date: Thu, 25 Jul 2013 15:38:26 -0700
Message-ID: 
 <CAJOjTCiOWPRdQRr45H_DCf+R9kOm3_OwiMjT+aG4rXam3rggVA@mail.gmail.com>
Subject: Re: Plugin / Platform mismatch problems
From: Benn Mapes <benn.mapes@gmail.com>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=047d7b111f3f37c32f04e25daf95

--047d7b111f3f37c32f04e25daf95
Content-Type: text/plain; charset=ISO-8859-1

+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?
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
>

--047d7b111f3f37c32f04e25daf95--