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 Thu, 25 Jul 2013 18:45:13 GMT
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