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 otherwise it won't be available onload. If we bump the MAJOR version then we can have a semblance of semver. I cringe to bring this topic up as it's been beaten to death but: we have a chance to start fresh with the plugin repos and might as well do it right! 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 >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 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 >>>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, "Shazron" <shaz...@gmail.com> wrote: >>> >>> >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 suppose >>>I >>> >could do a respondsToSelector, but that's just ugly) >>> >>> >>
