cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Plugin / Platform mismatch problems
Date Thu, 25 Jul 2013 18:44:14 GMT
Should probably tie into plugman as well, to not refer to plugins via
their id?

Does this make the id useless? Or does it provide value in a
multi-plugin-registry reality?

On 7/25/13 11:35 AM, "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