cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: Plugin / Platform mismatch problems
Date Thu, 25 Jul 2013 20:27:57 GMT
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