Not to mention - I believe if we upgrade our plugin to nodejs 0.8, it won't work with older versions of nodejs possibly - so that's another can of worms
On Mon, Jun 25, 2012 at 5:19 PM, Shazron <[email protected]> wrote: > Talked to Brian and Anis. > > It was explained to me that even numbered versions are considered > unstable, etc - so it's expected for devs to use a more stable > version. > > I'm just considering the most common scenario - where people will > download the latest node version 0.8 (regular dev users, not us) > > There's three approaches for us: > 1. They downloaded 0.8 - tell them to downgrade, using > https://github.com/isaacs/nave to 0.6 > 2. Upgrade our plugin to work with 0.8 > 3. Tell them to clean install 0.6 http://nodejs.org/dist/ > > My thinking is #2 would be easiest for users, but if we are going with > 0.6, we will have to document the steps etc for #1 and/or #3 > > Shaz > > On Mon, Jun 25, 2012 at 4:52 PM, Shazron <[email protected]> wrote: >> It's definitely a blocker IMO. 0.8 is the latest shipped version, and >> it doesn't work with it. >> Maybe you'll disagree, but users will. >> >> On Mon, Jun 25, 2012 at 4:36 PM, Filip Maj <[email protected]> wrote: >>> Yep, 0.6.8. >>> >>> $ node -v >>> v0.6.8 >>> >>> >>> On 6/25/12 4:32 PM, "Jesse" <[email protected]> wrote: >>> >>>>0.6.8 ? Is your toaster unplugged Fil? >>>>I am in windows and running without issue : >>>>$ node -v => v0.6.18 >>>> >>>> >>>>On Mon, Jun 25, 2012 at 4:29 PM, Filip Maj <[email protected]> wrote: >>>> >>>>> I wouldn¹t call that a blocker.. >>>>> >>>>> Pluginstall works fine with node 0.6.8 too. >>>>> >>>>> I was using 0.6.6, some dependencies in pluginstall require at least >>>>>node >>>>> 0.6.7, so I upgraded to 0.6.8. Works fine. >>>>> >>>>> On 6/25/12 3:59 PM, "Shazron" <[email protected]> wrote: >>>>> >>>>> >pluginstall blocker: >>>>> >https://github.com/alunny/node-xcode/issues/3 >>>>> >https://issues.apache.org/jira/browse/CB-631 >>>>> > >>>>> >Only works with node 0.6.17 >>>>> > >>>>> > >>>>> >On Mon, Jun 25, 2012 at 2:09 PM, Jesse <[email protected]> wrote: >>>>> >> We could use an 'engine' type specification similar to npm : >>>>> >> "engine": "node >= 0.4.1" >>>>> >> >>>>> >> >>>>> >> >>>>> >>>>>http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shri >>>>> >>nkwrap/ >>>>> >> >>>>> >> >>>>> >> On Mon, Jun 25, 2012 at 2:02 PM, Filip Maj <[email protected]> wrote: >>>>> >> >>>>> >>> Ideally, I would think we do NOT plan on doing that post-2.0. That >>>>> >>>said, >>>>> >>> our current deprecation policy, last I checked, was "6 months from >>>>> >>>now", >>>>> >>> which does not guarantee that the API will not change between minor >>>>> >>> revisions. >>>>> >>> >>>>> >>> Thus, the conversation turns back to project versioning and >>>>> >>>deprecation. >>>>> >>> >>>>> >>> Mike and I spoke about this this morning. I think both of us support >>>>> >>>the >>>>> >>> idea of moving to semantic versioning for 2.0 and beyond. >>>>> >>> >>>>> >>> On 6/25/12 1:45 PM, "Anis KADRI" <[email protected]> wrote: >>>>> >>> >>>>> >>> >Agreed fil, but are we planning on doing that for future releases ? >>>>> >>>If yes >>>>> >>> >that YAH we should support versions and the solution you described >>>>>is >>>>> >>> >certainly an option. But if I were a plugin developer, I would not >>>>> >>>want to >>>>> >>> >update it every month to keep up with Cordova releases. >>>>> >>> >I don't disagree that there could be an Cordova version in the >>>>> >>>manifest >>>>> >>> >file that allows plugin developers to target a specific version of >>>>> >>>Cordova >>>>> >>> >(which would mean that the plugin was tested with that version but >>>>> >>>might >>>>> >>> >also work with newer versions). >>>>> >>> > >>>>> >>> >On Mon, Jun 25, 2012 at 1:33 PM, Filip Maj <[email protected]> wrote: >>>>> >>> > >>>>> >>> >> Yes, it has changed every month. Pretty much every minor revision >>>>> >>>from >>>>> >>> >>1.0 >>>>> >>> >> to 1.9 has changed the API (at least on Android). >>>>> >>> >> >>>>> >>> >> On 6/25/12 1:26 PM, "Anis KADRI" <[email protected]> wrote: >>>>> >>> >> >>>>> >>> >> >Right but does the plugin interface change every month too ? A >>>>> >>>plugin >>>>> >>> >>that >>>>> >>> >> >works with Cordova 1.x.x is not supposed to work with Cordova >>>>> >>>1.y.y ? >>>>> >>> >> > >>>>> >>> >> >On Mon, Jun 25, 2012 at 1:18 PM, Filip Maj <[email protected]> >>>>>wrote: >>>>> >>> >> > >>>>> >>> >> >> You don't see any reason why plugins should support different >>>>> >>> >>versions >>>>> >>> >> >>of >>>>> >>> >> >> cordova? Cordova gets released every month. This seems like a >>>>> >>>pretty >>>>> >>> >> >> important thing to figure out IMO >>>>> >>> >> >> >>>>> >>> >> >> On 6/25/12 1:12 PM, "Anis KADRI" <[email protected]> wrote: >>>>> >>> >> >> >>>>> >>> >> >> >I think we should agree on a spec (plugin package and plugin >>>>> >>> >>interface) >>>>> >>> >> >> >and >>>>> >>> >> >> >stick to it. As long as we don't break the plugin interface, >>>>>I >>>>> >>>don't >>>>> >>> >> >>see >>>>> >>> >> >> >any reason why plugins should support multiple versions of >>>>> >>>Cordova. >>>>> >>> >>If >>>>> >>> >> >> >there are any, I'd love to hear them. >>>>> >>> >> >> > >>>>> >>> >> >> >On Mon, Jun 25, 2012 at 1:01 PM, Filip Maj <[email protected]> >>>>> >>>wrote: >>>>> >>> >> >> > >>>>> >>> >> >> >> Back onto the versioning question.. >>>>> >>> >> >> >> >>>>> >>> >> >> >> 1. Do we want to support different version of the cordova >>>>> >>> >>framework >>>>> >>> >> >>in >>>>> >>> >> >> >> plugins, within a single repo, across versions that changed >>>>> >>>the >>>>> >>> >> >> >> native/javascript plugin API? >>>>> >>> >> >> >> 2. How? >>>>> >>> >> >> >> >>>>> >>> >> >> >> If the answer to (1) is yes, one idea for (2) might be >>>>>nesting >>>>> >>> >> >>another >>>>> >>> >> >> >> directory level in the all of the source directories that >>>>> >>>contains >>>>> >>> >> >>the >>>>> >>> >> >> >> version number supported. For example: >>>>> >>> >> >> >> >>>>> >>> >> >> >> src/android/1.5.0/*.java >>>>> >>> >> >> >> src/android/1.8.1/*.java >>>>> >>> >> >> >> www/1.5.0/childbrowser.js >>>>> >>> >> >> >> www/1.8.1/childbrowser.js >>>>> >>> >> >> >> >>>>> >>> >> >> >> Could get gnarly real quick though. Another, cleaner >>>>> >>> >>implementation >>>>> >>> >> >>in >>>>> >>> >> >> >> terms of file system "noise" might be to employ a git >>>>>branches >>>>> >>> >> >> >> convention.. But that would enforce a git dependency. >>>>> >>> >> >> >> >>>>> >>> >> >> >> Just brainstorming / thinking out loud. Both are probably >>>>>bad >>>>> >>> >>ideas >>>>> >>> >> >>:) >>>>> >>> >> >> >> >>>>> >>> >> >> >> On 6/25/12 11:41 AM, "Michael Brooks" >>>>> >>><[email protected]> >>>>> >>> >> >>wrote: >>>>> >>> >> >> >> >>>>> >>> >> >> >> >We may also want to describe testing from JavaScript and >>>>> >>>Native. >>>>> >>> >> >> >> > >>>>> >>> >> >> >> >I would also like to see a repository called >>>>> >>> >> >>"cordova-plugin-template" >>>>> >>> >> >> >> >that >>>>> >>> >> >> >> >is a boilerplate to start writing any plugin. The idea is >>>>> >>>that >>>>> >>> >>users >>>>> >>> >> >> >>start >>>>> >>> >> >> >> >with something that works, with tests, and documentation >>>>> >>> >> >>boilerplate - >>>>> >>> >> >> >> >perhaps it can be an echo plugin since that has a minimal >>>>> >>> >>footprint. >>>>> >>> >> >> >> > >>>>> >>> >> >> >> >On Mon, Jun 25, 2012 at 11:28 AM, Filip Maj >>>>><[email protected]> >>>>> >>> >>wrote: >>>>> >>> >> >> >> > >>>>> >>> >> >> >> >> Looks great. I'll add some detail to the list you have >>>>> >>>here. >>>>> >>> >>I'd >>>>> >>> >> >> >> >>recommend >>>>> >>> >> >> >> >> tweaking the order a little bit; introducing the JS >>>>>before >>>>> >>>the >>>>> >>> >> >>native >>>>> >>> >> >> >> >>APIs. >>>>> >>> >> >> >> >> >>>>> >>> >> >> >> >> # Plugin Author Guide >>>>> >>> >> >> >> >> >>>>> >>> >> >> >> >> - plugin package format -> points to Andrew's plugin >>>>>spec >>>>> >>> >> >> >> >> - js api >>>>> >>> >> >> >> >> --- basically documenting exec(). Service, action, >>>>> >>>callbacks, >>>>> >>> >> >> >>arguments. >>>>> >>> >> >> >> >> What about how arguments are translated from JS types >>>>> >>>(string, >>>>> >>> >> >> >>number, >>>>> >>> >> >> >> >> objects, etc) to native types for each platform? >>>>> >>> >> >> >> >> >>>>> >>> >> >> >> >> - native api >>>>> >>> >> >> >> >> --- ios >>>>> >>> >> >> >> >> --- android >>>>> >>> >> >> >> >> --- blackberry >>>>> >>> >> >> >> >> --- windowsphone >>>>> >>> >> >> >> >> --- bada >>>>> >>> >> >> >> >> >>>>> >>> >> >> >> >> >>>>> >>> >> >> >> >> On 6/25/12 11:16 AM, "Brian LeRoux" <[email protected]> wrote: >>>>> >>> >> >> >> >> >>>>> >>> >> >> >> >> >Biggest question is how to document. My thinking is >>>>>that >>>>> >>>we >>>>> >>> >>want >>>>> >>> >> >>to >>>>> >>> >> >> >> >> >specify the PluginPackage so that PluginInstall works. >>>>>So >>>>> >>>the >>>>> >>> >> >>docs >>>>> >>> >> >> >> >> >would read like this: >>>>> >>> >> >> >> >> > >>>>> >>> >> >> >> >> ># Plugin Author Guide >>>>> >>> >> >> >> >> > >>>>> >>> >> >> >> >> >- plugin package format >>>>> >>> >> >> >> >> >- native api >>>>> >>> >> >> >> >> >--- ios >>>>> >>> >> >> >> >> >--- android >>>>> >>> >> >> >> >> >--- blackberry >>>>> >>> >> >> >> >> >--- windowsphone >>>>> >>> >> >> >> >> >--- bada >>>>> >>> >> >> >> >> >- js api >>>>> >>> >> >> >> >> > >>>>> >>> >> >> >> >> >Thoughts? (If this looks good I will update the issue.) >>>>> >>> >> >> >> >> > >>>>> >>> >> >> >> >> > >>>>> >>> >> >> >> >> > >>>>> >>> >> >> >> >> >On Mon, Jun 25, 2012 at 10:50 AM, Filip Maj >>>>> >>><[email protected]> >>>>> >>> >> >>wrote: >>>>> >>> >> >> >> >> >> Hah Michael and I were just talking about that.. >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> I will send a pull request to Andrew's draft spec >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> On 6/25/12 10:46 AM, "Brian LeRoux" <[email protected]> >>>>>wrote: >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >>>npm does this w/ an 'engines' attribute on >>>>>package.json >>>>> >>> >> >> >> >> >>> >>>>> >>> >> >> >> >> >>>On Mon, Jun 25, 2012 at 10:26 AM, Filip Maj >>>>> >>><[email protected]> >>>>> >>> >> >> wrote: >>>>> >>> >> >> >> >> >>>> One more thing that came to mind is how to support >>>>> >>> >>different >>>>> >>> >> >> >> >>versions >>>>> >>> >> >> >> >> >>>>of Cordova? Any ideas? >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> From: Andrew Lunny >>>>> >>> >> >><[email protected]<mailto:[email protected]>> >>>>> >>> >> >> >> >> >>>> Reply-To: >>>>>"[email protected]<mailto:[email protected]>" >>>>> >>> >> >> >> >> >>>><[email protected]<mailto:[email protected]>> >>>>> >>> >> >> >> >> >>>> To: Default User Nam >>>>> >>><[email protected]<mailto:[email protected] >>>>> >>> >> >>>>> >>> >> >> >> >> >>>> Cc: >>>>> >>> >> >> >> >> >>>>"[email protected]<mailto: >>>>> >>> >> >> >> >> [email protected] >>>>> >>> >> >> >> >> >>>>.o >>>>> >>> >> >> >> >> >>>>rg>" >>>>> >>> >> >> >> >> >>>><[email protected]<mailto: >>>>> >>> >> >> >> >> [email protected] >>>>> >>> >> >> >> >> >>>>.o >>>>> >>> >> >> >> >> >>>>rg>> >>>>> >>> >> >> >> >> >>>> Subject: Re: Plugin Format and Spec >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> On 11 June 2012 13:50, Filip Maj >>>>> >>> >> >> >> >><[email protected]<mailto:[email protected] >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >>>>wrote: >>>>> >>> >> >> >> >> >>>> Nice work Andrew! I suggest taking this and moving >>>>>to >>>>> >>>a >>>>> >>> >> >>cordova >>>>> >>> >> >> >> >>wiki >>>>> >>> >> >> >> >> >>>>page >>>>> >>> >> >> >> >> >>>> (assuming all committers are on board to adopting >>>>> >>>this as >>>>> >>> >>the >>>>> >>> >> >> >>basis >>>>> >>> >> >> >> >> >>>>for >>>>> >>> >> >> >> >> >>>>a >>>>> >>> >> >> >> >> >>>> plugin spec) >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> A link on the Cordova wiki is probably the best >>>>>place >>>>> >>>to >>>>> >>> >> >>start >>>>> >>> >> >> >>- we >>>>> >>> >> >> >> >> >>>>can >>>>> >>> >> >> >> >> >>>>get some more feedback from plugin authors and app >>>>> >>> >>developers >>>>> >>> >> >> >>(i.e. >>>>> >>> >> >> >> >> >>>>keep >>>>> >>> >> >> >> >> >>>>this as "a way to write plugins" rather than "the >>>>> >>>official >>>>> >>> >> >>way to >>>>> >>> >> >> >> >>write >>>>> >>> >> >> >> >> >>>>plugins"). >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> Is target-dir necessary for the <source-file> >>>>> >>>element? For >>>>> >>> >> >>Java >>>>> >>> >> >> >> >>files, >>>>> >>> >> >> >> >> >>>>the >>>>> >>> >> >> >> >> >>>> tooling could take a peak inside the .java file and >>>>> >>> >>extract >>>>> >>> >> >>out >>>>> >>> >> >> >>the >>>>> >>> >> >> >> >> >>>> package name from the file, no? Phonegap build >>>>>already >>>>> >>> >>does >>>>> >>> >> >>this >>>>> >>> >> >> >> >> >>>>doesn't >>>>> >>> >> >> >> >> >>>> it? >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> PhoneGap Build did do this, but no longer supports >>>>> >>> >>uploading >>>>> >>> >> >> >> >>arbitrary >>>>> >>> >> >> >> >> >>>>Java files. Only plugins with a manifest are >>>>>supported. >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> I'm torn - one of the goals of this format is to >>>>>make >>>>> >>>it >>>>> >>> >>as >>>>> >>> >> >> >>easy as >>>>> >>> >> >> >> >> >>>>possible to write tools that use it as possible. >>>>>Right >>>>> >>> >>now, a >>>>> >>> >> >> >>tool >>>>> >>> >> >> >> >> >>>>reads >>>>> >>> >> >> >> >> >>>>one file (plugin.xml) and moves source files >>>>>(ignoring >>>>> >>> >>config >>>>> >>> >> >> >>files >>>>> >>> >> >> >> >>for >>>>> >>> >> >> >> >> >>>>the moment). I'd prefer it wasn't "read one file, >>>>>then >>>>> >>>read >>>>> >>> >> >>each >>>>> >>> >> >> >> >>.java >>>>> >>> >> >> >> >> >>>>file to discover where to move it". >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> One option is to use the id attribute on the >>>>>top-level >>>>> >>> >>plugin >>>>> >>> >> >> >> >>element >>>>> >>> >> >> >> >> >>>>to resolve the path, but that doesn't handle the >>>>>case >>>>> >>>where >>>>> >>> >> >> >> >>different >>>>> >>> >> >> >> >> >>>>Java files will have different paths. I wonder if >>>>> >>>there are >>>>> >>> >> >>more >>>>> >>> >> >> >> >> >>>>complex >>>>> >>> >> >> >> >> >>>>plugins around we can try to convert to see where >>>>>the >>>>> >>>pain >>>>> >>> >> >>points >>>>> >>> >> >> >> >>are. >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> Adding the ability to modify existing parts of a >>>>> >>>native >>>>> >>> >> >> >>platform's >>>>> >>> >> >> >> >> >>>>config >>>>> >>> >> >> >> >> >>>> document to the <config-file> portion might be >>>>> >>>needed.. >>>>> >>> >> >>Although >>>>> >>> >> >> >> >>Ive >>>>> >>> >> >> >> >> >>>>yet >>>>> >>> >> >> >> >> >>>> to dig up a use case. Will dig around more. >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> Agreed - also things like target OS/SDK versions >>>>>may >>>>> >>>be >>>>> >>> >> >> >>required by >>>>> >>> >> >> >> >> >>>>certain plugins (i.e. this plugin uses an iOS 6 API, >>>>> >>>so we >>>>> >>> >> >>need >>>>> >>> >> >> >>to >>>>> >>> >> >> >> >> >>>>update your project to iOS 6). Probably the best >>>>> >>>approach >>>>> >>> >> >>there >>>>> >>> >> >> >>is >>>>> >>> >> >> >> >>to >>>>> >>> >> >> >> >> >>>>warn/prompt the user before proceeding. >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> +1 agree that <resource-file> and <header-file> is >>>>> >>> >>redundant. >>>>> >>> >> >> >> >>Tooling >>>>> >>> >> >> >> >> >>>> should be able to distinguish this so merging with >>>>> >>> >> >><source-file> >>>>> >>> >> >> >> >> >>>>makes a >>>>> >>> >> >> >> >> >>>> lot of sense. >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> Looking good! >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> On 6/8/12 6:40 PM, "Andrew Lunny" >>>>> >>> >> >> >> >> >>>><[email protected]<mailto:[email protected]>> wrote: >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>>>Hi all, >>>>> >>> >> >> >> >> >>>>> >>>>> >>> >> >> >> >> >>>>>I've posted to this list before about >>>>>pluginstall[1], >>>>> >>>the >>>>> >>> >> >>tool >>>>> >>> >> >> >>I've >>>>> >>> >> >> >> >> >>>>>developed as part of working on PhoneGap Build and >>>>> >>> >>requiring >>>>> >>> >> >> >> >> >>>>>programmatic >>>>> >>> >> >> >> >> >>>>>installation of Cordova plugins. >>>>> >>> >> >> >> >> >>>>> >>>>> >>> >> >> >> >> >>>>>I've now written up a spec for the format that >>>>> >>>pluginstall >>>>> >>> >> >>uses >>>>> >>> >> >> >>- I >>>>> >>> >> >> >> >> >>>>>think >>>>> >>> >> >> >> >> >>>>>it's generally useful for Cordova plugin >>>>>installation >>>>> >>>and >>>>> >>> >> >> >> >> >>>>>manipulation. >>>>> >>> >> >> >> >> >>>>>The >>>>> >>> >> >> >> >> >>>>>spec is available on GitHub: >>>>> >>> >> >> >> >> >>>>>https://github.com/alunny/cordova-plugin-spec >>>>> >>> >> >> >> >> >>>>> >>>>> >>> >> >> >> >> >>>>>Issues and/or pull requests and/or forks welcome. >>>>> >>> >> >> >> >> >>>>> >>>>> >>> >> >> >> >> >>>>>Cheers, >>>>> >>> >> >> >> >> >>>>>Andrew >>>>> >>> >> >> >> >> >>>>> >>>>> >>> >> >> >> >> >>>>>[1] https://github.com/alunny/pluginstall >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >>>> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >>>>> >>> >> >> >> >> >>>>> >>> >> >> >> >>>>> >>> >> >> >> >>>>> >>> >> >> >>>>> >>> >> >> >>>>> >>> >> >>>>> >>> >> >>>>> >>> >>>>> >>> >>>>> >> >>>>> >> >>>>> >> -- >>>>> >> @purplecabbage >>>>> >> risingj.com >>>>> >>>>> >>>> >>>> >>>>-- >>>>@purplecabbage >>>>risingj.com >>>
