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
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
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.
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
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 engine, and sdk/os in platform.
The JS version is the same as the platform version (at least
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
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 f...@adobe.com wrote:
Npm will only retrieve matching versions based on the package.json's
version, which I think correlates to the plugin.xml's
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 anis.ka...@gmail.com wrote:
It doesn't right now. But it could and would not be a huge effort I
think. Create an issue for it maybe
For sure!
On Thu, Jul 25, 2013 at 11:11 AM, Filip Maj f...@adobe.com 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 anis.ka...@gmail.com wrote:
It doesn't right now.
So when cordova adding plugins it does an engine 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
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 engine tag or
the platform tag in plugin.xml, but I think that the platform tag is
the
What about this as a rule of thumb for plugins:
If the engine 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
I like it existing in the platform 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 f...@adobe.com wrote:
What about this as a rule of thumb for plugins:
If the engine requirements within a plugin's XML if bumped up, we
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 shaz...@gmail.com wrote:
I like it existing in the platform tag as Tim suggested.
Fil - that makes sense, we should doc
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 shaz...@gmail.com wrote:
In any case I'm taking the easy way out for now and just fixing the code
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 param
name=unload value=true / added to the feature tag
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
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 anis.ka...@gmail.com wrote:
Hey all,
Plugins need to be versioned to be backward compatible with previous
+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
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:
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 f...@adobe.com wrote:
What Michael says seems to make the most
22 matches
Mail list logo
