Github user asfgit closed the pull request at:
https://github.com/apache/cordova-docs/pull/608
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature i
Github user stevengill commented on the issue:
https://github.com/apache/cordova-docs/pull/608
@fredgalvao, I agree that there would be benefits to implementing it. Feel
free to open a feature request issue at issues.cordova.io.
Regardless, this PR is to fix the docs issue.
Github user fredgalvao commented on the issue:
https://github.com/apache/cordova-docs/pull/608
Why not implement it instead? I'd bet `cordova plugin rm XXX && cordova
plugin add XXX` is a very common thing, and a `cordova plugin update XXX` could
be usefull.
I've had situati
Github user stevengill commented on the issue:
https://github.com/apache/cordova-docs/pull/608
Thanks @carynbear! I don't think we ever supported a plugin update command.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. I
GitHub user carynbear opened a pull request:
https://github.com/apache/cordova-docs/pull/608
Update platform/plugin versioning
Remove cordova plugin update (this command does not seem to exist)
You can merge this pull request into a Git repository by running:
$ git pull https
For sure!
On Thu, Jul 25, 2013 at 11:11 AM, Filip Maj wrote:
> Yeh sure. Maybe we can brainstorm some implementation ideas and greenfield
> it today/tomorrow since we're in the same location dude?
>
> On 7/25/13 11:00 AM, "Anis KADRI" wrote:
>
>>It doesn't right now. But it could and would not b
Yeh sure. Maybe we can brainstorm some implementation ideas and greenfield
it today/tomorrow since we're in the same location dude?
On 7/25/13 11:00 AM, "Anis KADRI" wrote:
>It doesn't right now. But it could and would not be a huge effort I
>think. Create an issue for it maybe ?
>
>On Thu, Jul
It doesn't right now. But it could and would not be a huge effort I
think. Create an issue for it maybe ?
On Thu, Jul 25, 2013 at 8:44 AM, Filip Maj wrote:
> Npm will only retrieve matching versions based on the package.json's
> version, which I think correlates to the plugin.xml's version attrib
Npm will only retrieve matching versions based on the package.json's
version, which I think correlates to the plugin.xml's version attribute. I
don't think npm's features will work for us out of the box as it relies on
dependencies specified in package.json. UNLESS Anis' implementation
somehow tran
semver says that you bump major when there's a non-backwards-compatible
change. Adding the onload= attribute *is* a backwards-compatible change
unless I'm mistaken.
I like the suggestion of CDV version in , and sdk/os in .
The JS version is the same as the platform version (at least for releases).
I would like to revise my rule of thumb to:
If the plugin.xml is changed, we must bump the plugin's MAJOR version.
Brought up with https://issues.apache.org/jira/browse/CB-4374
In the above case, the splash screen plugin needs to have a added to the tag otherwise it
won't be available onload.
Let's kick up a new section in the Release wiki document to cover how to
handle plugins.
We can discuss in more details when we schedule our post-3.0 committer
meeting.
On 7/24/13 3:27 PM, "Shazron" wrote:
>In any case I'm taking the easy way out for now and just fixing the code
>and not adding
In any case I'm taking the easy way out for now and just fixing the code
and not adding that new selector to the commanddelegate :P
On Wed, Jul 24, 2013 at 3:18 PM, Shazron wrote:
> I like it existing in the tag as Tim suggested.
>
> Fil - that makes sense, we should doc all these rules
>
>
>
I like it existing in the tag as Tim suggested.
Fil - that makes sense, we should doc all these rules
On Wed, Jul 24, 2013 at 3:14 PM, Filip Maj wrote:
> What about this as a rule of thumb for plugins:
>
> If the requirements within a plugin's XML if bumped up, we MUST
> bump the plugin's MA
What about this as a rule of thumb for plugins:
If the requirements within a plugin's XML if bumped up, we MUST
bump the plugin's MAJOR version
Since we're versioning plugins on their own it should be fine, ya? Kind of
like how the tooling is versioned on its own pretty much.
On 7/24/13 2:39 PM
Ya, it does an engine/version check but only for cordova js - it currently
does nothing about the os/sdk versions of the platform you're deving for. I
was thinking about handling the check for os/sdk within the tag or
the tag in plugin.xml, but I think that the tag is
the better choice.
If we
So when cordova adding plugins it does an check, yes?
I've got this situation where I want to add a new method to
CDVCommandDelegate (see my last comment in the issue below):
https://issues.apache.org/jira/browse/CB-4355
Basically I want to do this with minimal hassle to devs... (I suppose I
cou
I'm a little confused. Would we not specify the plugin version in the
config.xml?? Plugins that get published most certainly need to be
versioned on the discovery server side too of course..
On Tue, Mar 19, 2013 at 1:03 PM, Filip Maj wrote:
> What Michael says seems to make the most sense.
>
> On
What Michael says seems to make the most sense.
On 3/19/13 11:44 AM, "Michael Brooks" wrote:
>>
>> However, It's expensive to clone down the
>> repository just to check if the plugin works or not.
>
>
>Good point Anis, it would be expensive to clone down a plugin simply to
>disc
>
>
>> I believe
>
> However, It's expensive to clone down the
> repository just to check if the plugin works or not.
Good point Anis, it would be expensive to clone down a plugin simply to disc
> I believe we should store some sort of mapping on our discovery server.
> Such as:
> {
> cordova_version: plugin_
+1
However, I think we may need a better property/value pair name than
just cordova_version:
plugin_versions. This is because I feel like there is a implicit idea that
this particular plugin will work on a specific version of Cordova, but for
all platforms. Whereas in reality, most of the plugins
Sounds good. Let me introduce yet another headache - config.xml changes.
Case in point, the change of the root element from "cordova" to "widget". I
filed an issue here: https://issues.apache.org/jira/browse/CB-2727
Copied below:
plugin.xml:
https://github.com/shazron/ZipUtil/blob/a0
That sounds reasonable to me.
How would this be maintained? Would there be some automated process that
keeps that mapping up-to-date?
On Tue, Mar 19, 2013 at 10:59 AM, Anis KADRI wrote:
> Hey all,
>
> Plugins need to be versioned to be backward compatible with previous
> versions of Cordova. I
Hey all,
Plugins need to be versioned to be backward compatible with previous
versions of Cordova. I had a discussion with the PhoneGap:Build team
yesterday and they need to be backward compatible. Ally Ogilvie also
mentioned in separate thread that game developers would also need something
like t
24 matches
Mail list logo
