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. 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) >>>>> >>> >>>>> >>> >>>>> >> >>>>> >>>>> >>> >
