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 ? > >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 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 transforms <dependency> elements from our plugin.xml into >>correct >> "dependencies" properties in the resulting package.json. >> >> On 7/25/13 7:13 AM, "Andrew Grieve" <agri...@chromium.org> wrote: >> >>>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 for >>>releases). >>> >>>Does anyone know if npm automatically finds packages that match your >>>stated >>>engine? >>>e.g. >>> - plugin-camera-1.0.0 minimum target of 3.0.0, maximum target of 3.0.0 >>> - plugin-camera-2.0.0 minimum target of 3.1.0, no maximum target >>> >>>I have 3.0.0 for my project and do a plugman install plugin-camera. Will >>>npm figure out that I want version 1.0.0? >>> >>> >>> >>> >>>On Thu, Jul 25, 2013 at 1:42 AM, Filip Maj <f...@adobe.com> wrote: >>> >>>> 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) >>>> >>> >>>> >>> >>>> >> >>>> >>>> >>
