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