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:28:02 GMT
Yeah we can use id and keep name around for human readable purpose.

I am fine with it. I just think that typing giant package names is
just not user friendly from a developer's perspective. Maybe it's just
me.

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