Yes 0.8.x is stable, so we should be expecting more and more people to move to it soon.
Cheers, Jesse Sent from my iPhone5 On 2012-06-25, at 5:20 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 >>>
