Re: cli plugins 'alias'?
I don't really think we need this feature: (1) We already have plugin's which support dependencies. Combined with the plugin repository, this means your alias feature is equivalent to creating a do-nothing plugin that specifies its dependencies. (2) Also, we will soon have a way to specify application template (ie, replace hello world), which combined with plugin dependencies for apps, means that creating mobile spec will be as easy as `cordova create PATH_TO_MOBILE_SPEC` and adding platforms. -Michal On Mon, Sep 2, 2013 at 9:40 PM, lmnbeyond lmnbey...@gmail.com wrote: + 1 It's great Best Regards! On 2013-9-3, at 上午8:37, Brian LeRoux b...@brian.io wrote: love this idea On Sat, Aug 31, 2013 at 2:36 PM, Jonathan Bond-Caron jbo...@gdesolutions.com wrote: Setting up the mobile spec app was tedious since I didn't know the dependencies. I wrote a small patch that allows to pull a plugin from a git subdirectory e.g. cordova plugin add https://github.com/jbondc/cordova-labs?subdir=cordova-deps-mobile-spec https://issues.apache.org/jira/browse/CB-4715 It got me thinking there might an opportunity to make this less tedious with an 'alias' e.g. cordova plugin add @cordova-test The @ symbol signals an 'alias' (cordova-test) that cli would expand to https://.../cordova-plugin-battery-status https:// .../cordova-plugin-device etc... The list of plugins simply gets passed to plugman. A couple of 'core' aliases could make it easier to get started with cordova, e.g. cordova plugin add @cordova-common cordova plugin add @cordova-test cordova plugin rm @cordova-test Could also be called packaged / collection / grouped plugins. Thoughts?
Re: cli plugins 'alias'?
Just updated the README.md to remove the pre-3.0 setup instructions. On Tue, Sep 3, 2013 at 9:53 AM, Michal Mocny mmo...@chromium.org wrote: I don't really think we need this feature: (1) We already have plugin's which support dependencies. Combined with the plugin repository, this means your alias feature is equivalent to creating a do-nothing plugin that specifies its dependencies. (2) Also, we will soon have a way to specify application template (ie, replace hello world), which combined with plugin dependencies for apps, means that creating mobile spec will be as easy as `cordova create PATH_TO_MOBILE_SPEC` and adding platforms. -Michal On Mon, Sep 2, 2013 at 9:40 PM, lmnbeyond lmnbey...@gmail.com wrote: + 1 It's great Best Regards! On 2013-9-3, at 上午8:37, Brian LeRoux b...@brian.io wrote: love this idea On Sat, Aug 31, 2013 at 2:36 PM, Jonathan Bond-Caron jbo...@gdesolutions.com wrote: Setting up the mobile spec app was tedious since I didn't know the dependencies. I wrote a small patch that allows to pull a plugin from a git subdirectory e.g. cordova plugin add https://github.com/jbondc/cordova-labs?subdir=cordova-deps-mobile-spec https://issues.apache.org/jira/browse/CB-4715 It got me thinking there might an opportunity to make this less tedious with an 'alias' e.g. cordova plugin add @cordova-test The @ symbol signals an 'alias' (cordova-test) that cli would expand to https://.../cordova-plugin-battery-status https:// .../cordova-plugin-device etc... The list of plugins simply gets passed to plugman. A couple of 'core' aliases could make it easier to get started with cordova, e.g. cordova plugin add @cordova-common cordova plugin add @cordova-test cordova plugin rm @cordova-test Could also be called packaged / collection / grouped plugins. Thoughts?
Re: What's your daily workflow for cordova development?
I do like the idea of a `plugin watch` command, but I think we need to consider a few points: Our current plan for plugin upgrade is to plugin rm plugin add. So, we need an keep immutable copy of the original plugin as it was during install time in order to uninstall correctly (thought: maybe we only need the original plugin.xml?). I think that is the purpose of the plugins/ directory, more than anything else right now. If we want to support any live plugin dev, it would currently need to be in a different directory location (outside plugins/ folder). I really don't like that fact (seems @devgeeks agrees). Perhaps we can fix this situation if all thats needed is the original plugin.xml.. Also, perhaps we also add a plugin create command to set up a plugin template? -Michal On Mon, Sep 2, 2013 at 9:49 PM, lmnbeyond lmnbey...@gmail.com wrote: + 1 love watch command idea :) Best Regards! On 2013-9-3, at 上午7:34, Brian LeRoux b...@brian.io wrote: automate add/remove with some sort of watch command. That way ppl are writing to the plugin spec from the beginning instead of refactoring a plugin out of a native project.
Cutting down on size of docs
Anyone opposed if I delete the old rc versions of docs (e.g. ite/public/docs/en/1.9.0rc1) They bloat the repo and I don't think add any value.
Re: cli plugins 'alias'?
Agreed with Michal. There's actually a third option coming too: we want apps to be able to name dependencies. So you should be able to copy in the mobile-spec app, then `cordova plugin add` or whatever the syntax becomes, and it will install all of the app's dependencies. Braden On Tue, Sep 3, 2013 at 10:00 AM, Andrew Grieve agri...@chromium.org wrote: Just updated the README.md to remove the pre-3.0 setup instructions. On Tue, Sep 3, 2013 at 9:53 AM, Michal Mocny mmo...@chromium.org wrote: I don't really think we need this feature: (1) We already have plugin's which support dependencies. Combined with the plugin repository, this means your alias feature is equivalent to creating a do-nothing plugin that specifies its dependencies. (2) Also, we will soon have a way to specify application template (ie, replace hello world), which combined with plugin dependencies for apps, means that creating mobile spec will be as easy as `cordova create PATH_TO_MOBILE_SPEC` and adding platforms. -Michal On Mon, Sep 2, 2013 at 9:40 PM, lmnbeyond lmnbey...@gmail.com wrote: + 1 It's great Best Regards! On 2013-9-3, at 上午8:37, Brian LeRoux b...@brian.io wrote: love this idea On Sat, Aug 31, 2013 at 2:36 PM, Jonathan Bond-Caron jbo...@gdesolutions.com wrote: Setting up the mobile spec app was tedious since I didn't know the dependencies. I wrote a small patch that allows to pull a plugin from a git subdirectory e.g. cordova plugin add https://github.com/jbondc/cordova-labs?subdir=cordova-deps-mobile-spec https://issues.apache.org/jira/browse/CB-4715 It got me thinking there might an opportunity to make this less tedious with an 'alias' e.g. cordova plugin add @cordova-test The @ symbol signals an 'alias' (cordova-test) that cli would expand to https://.../cordova-plugin-battery-status https:// .../cordova-plugin-device etc... The list of plugins simply gets passed to plugman. A couple of 'core' aliases could make it easier to get started with cordova, e.g. cordova plugin add @cordova-common cordova plugin add @cordova-test cordova plugin rm @cordova-test Could also be called packaged / collection / grouped plugins. Thoughts?
RE: What's your daily workflow for cordova development?
On Mon Sep 2 07:34 PM, Brian LeRoux wrote: Here's a shot. Ideal flow tomorrow might be to generate a plugin called, lets say, Echo that matches something we'd find in our docs, automate add/remove with some sort of watch command. That way ppl are writing to the plugin spec from the beginning instead of refactoring a plugin out of a native project. Thoughts? Two new features could be useful from cli: a) Create an initial plugin from a template cordova plugin create [path] [name] e.g. cordova plugin create F:/GitHub/MyPlugin MyPlugin b) Update all plugins from a cordova application cordova plugins update e.g. cordova create F:/CordovaApp cd F:/CordovaApp cordova plugin add F:/GitHub/MyPlugin cordova plugins update The implementation is likely tricky, how to detect plugin modification? Version check? I image it would remove install the new plugin. cordova plugins update -local Could be useful to force the removal and reinstall of only local plugins (from a filesystem path) / under development... I haven't gotten around to running .spec tests but something simple as: c) Running tests within plugin directory cd F:/GitHub/MyPlugin cordova plugin test [Test #1] Passed [Test #2] Failed: Reference error foo doesn't not exist Would be very useful.
Re: Serve vs. opening an HTML file in the browser
Ok, I forgot to run cordova serve. I did, and then I get the same behavior as before. A prompt and then infinite console.log messages. On 9/2/13 8:32 PM, Gord Tanner gtan...@gmail.com wrote: Good news! I have a branch that is booting projects made with cordova 3.0 [1]. It is basically a stripped down platform and I tested it booting a project with android and ios. To run: cordova create Baz cordova platform add android cordova prepare ripple emulate (make sure you pick cordova 3.0.0) I was noticing that when I ran cordova serve android it wouldn't have the cordova_plugins.js file. Next Steps: - audit API's that are emulated and ensure they are up to spec (most are just using the 2.0 emulated versions) - reintegrate with cordova cli. Let me know if you take this for a test drive and have any problems. Gord
When to update version numbers?
For repos that use SemVer, there are two options: 1. Update the version number at the time that the change is made 2. Update the version number only when doing a release. Right now, #2 is what I've put in the wiki instructions, but it can be changed of course :) Two main reasons I think #2 will work better: - #1 might be too complicated (might forget to update it, may update the version multiple times if multiple feature changes go in) - #2 If doing a release, you should know what you're releasing. Having to choose the right version number will force you to understand what you're releasing.
Re: Releases in a 3.0 World
Finally finished updating the wiki's instructions to follow this proposal. Summary of changes: https://wiki.apache.org/cordova/VersioningAndReleaseStrategy - Explains our versioning strategy (SemVer vs CadVer) https://wiki.apache.org/cordova/CommitterWorkflow - Extracted Pull Requst Processing into its own page ( ProcessingPullRequestshttps://wiki.apache.org/cordova/ProcessingPullRequests ) - Added a Which Branch to Commit To section - Minor tweaks to commit process: - Mention `git rebase origin/master -i` - Marked some steps as optional - Linked to post-review (rbtools) install page - Made it more explicit that you should test commits you patch in https://wiki.apache.org/cordova/StepsForPluginRelease - Process to go through to update core plugins https://wiki.apache.org/cordova/StepsForToolsRelease - Process to go through to update plugman / CLI https://wiki.apache.org/cordova/CuttingReleases - Made it clear that it applies to Cadence Releases - Expanded What to test section - Added releasing of CLI to the steps - Moved Official Apache Releases to the bottom To all steps release steps pages, I've added an Update CHANGELOG.md step. iOS has done this forever, but I think all repos should do it. Would love if these pages could be read by all committers. Especially the StepsForToolsRelease page, as I've never done a tools release (and so was somewhat guessing). Another part I'm unsure of is where the mapping to platform repo versions is within CLI. There are still some points to discuss, which I will send separate emails about :) On Sun, Aug 18, 2013 at 11:30 PM, Ian Clelland iclell...@google.com wrote: On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve agri...@chromium.org wrote: After the discussion on the group hangout + some sleeping, I think we're ready for a proposal... So here it is! - It does *not* propose any changes to our Deprecation policy. That's for another thread (which I'll get to on Monday if no one else does) :) - It does not contain how we store version numbers. That's covered here: http://wiki.apache.org/cordova/StoringRepoVersionsDesign Once we get to a consensus, I'll transfer this to the wiki. Please review comment! There are two kinds of versions: 1. SemVer (www.semver.org) - Used by platforms, plugman, cli 2. CadVer (just made that up :P Cadence Version) - Used by cli, mobile-spec, cordova-js I like this, as it separates the fast-moving, feature-based semantic version of any given component from the API level, and interoperability promises, of the Cadence Version. What, then, is the granularity of the Cadence Version intended to be? Is is the 3 in Cordova 3.0, and will stay at 3 until it hits 4 next year? (Or, just as descriptively, we can say that it is at Cordova Fancy-Pants now, and eventually progress to Cordova Enraged-Wombat) Or is it going to have major and minor components as well, and advance roughly monthly, as before? There are two kinds of releases: 1. Patch releases - Pretty much any repo can release a patch release to fix bugs at any time (but should have good reason) 2. Cadence releases - These follow the 10 releases per year, as enumerated on: http://wiki.apache.org/cordova/RoadmapProjects cordova-plugins: - Commit only to the `dev` branch - Use semver for them. - If the version on master is 3.0.0, then the version on dev will start at 3.0.1-dev. - If any commit goes in that add a feature, then change the version on dev to 3.1.0-dev - If any commit goes in that makes an non-backwards-compatible change, then change the version on dev to 4.0.0-dev - Release plugins at most once a week (Thursdays?) - This *does* mean that a change that goes in Wednesday could end up being released the next day. - Release plugins all at the same time so that we can blog the release notes. - Release process: 1. Create a JIRA issue to track the status of the release. a. Comments should be added to this bug after each top-level step below is taken 2. For each plugin that has unreleased commits on their `dev` branch: a. Update its CHANGELOG file with a prettified version of git log b. Update its plugin.xml version by removing the -dev suffix c. Merge dev - master (without pushing) d. Update its plugin.xml version by incrementing the micro and adding -dev (as described above) 3. Combine all plugin changelogs into a Release announcement blog post on cordova-website. a. Steps for this exist in cordova-website's README.md 4. Test a. Create mobilespec using the old versions of plugins b. Perform a plugin upgrade for plugins that have changes (right now, this means doing a `plugin remove` followed by a `plugin add` c. Run through mobilespec, ensuring to do manual tests that relate to changes in the changelog 5. Push! a. Push
Re: Serve vs. opening an HTML file in the browser
Wildshot: localhost:4400/ripple ? On Tue, Sep 3, 2013 at 12:08 PM, Ray Camden rayca...@adobe.com wrote: Ok, forgive me if I did something stupid here. I cloned https://github.com/apache/incubator-ripple/tree/cordova-3.0. I did configure, jake, and then in Chrome I installed the unpacked extension. I chose pkg/chrome.extension. Of the three folders I assume that is the right one. I then made a new project as described below, and run ripple from /whereIclone/bin/ripple and I get this in terminal: INFO: Server instance running on: http://localhost:4400 INFO: CORS XHR proxy service on: http://localhost:4400/ripple/xhr_proxy INFO: JSONP XHR proxy service on: http://localhost:4400/ripple/jsonp_xhr_proxy I then tried to hit localhost:4400 and I get Cannot GET /. On 9/2/13 8:32 PM, Gord Tanner gtan...@gmail.com wrote: Good news! I have a branch that is booting projects made with cordova 3.0 [1]. It is basically a stripped down platform and I tested it booting a project with android and ios. To run: cordova create Baz cordova platform add android cordova prepare ripple emulate (make sure you pick cordova 3.0.0) I was noticing that when I ran cordova serve android it wouldn't have the cordova_plugins.js file. Next Steps: - audit API's that are emulated and ensure they are up to spec (most are just using the 2.0 emulated versions) - reintegrate with cordova cli. Let me know if you take this for a test drive and have any problems. Gord [1] - https://github.com/apache/incubator-ripple/tree/cordova-3.0 On Wed, Aug 28, 2013 at 6:21 AM, Ray Camden rayca...@adobe.com wrote: On 8/27/13 11:41 PM, Gord Tanner gtan...@gmail.com wrote: I think with some tweaks we could have ripple working on all platform cordova.js files again. I am going to need to version out a new platform for cordova to handle the updated hacks and overrides to boot each platform cleanly but doesn't seem like an impossible task. If you need someone to help test, just let me know. -rc
Re: When to update version numbers?
+1 for option #2 On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve agri...@chromium.org wrote: For repos that use SemVer, there are two options: 1. Update the version number at the time that the change is made 2. Update the version number only when doing a release. Right now, #2 is what I've put in the wiki instructions, but it can be changed of course :) Two main reasons I think #2 will work better: - #1 might be too complicated (might forget to update it, may update the version multiple times if multiple feature changes go in) - #2 If doing a release, you should know what you're releasing. Having to choose the right version number will force you to understand what you're releasing.
When to do Official Apache Releases
It's been mentioned before, but with CLI, there's not a lot of utility in doing official apache releases (uploading signed zips to dist.apache.org). I don't think we should stop doing these entirely, but should we still do these for each Cadence Release? An alternative would be to do them only once / twice a year. Any thoughts on why / why not? Andrew
RE: cli plugins 'alias'?
On Tue Sep 3 10:47 AM, Braden Shepherdson wrote: Agreed with Michal. There's actually a third option coming too: we want apps to be able to name dependencies. So you should be able to copy in the mobile- spec app, then `cordova plugin add` or whatever the syntax becomes, and it will install all of the app's dependencies. I'm less a fan of 'app dependencies', lots of frameworks and ways of thinking about how to organize an application. Is this a W3C, HTML5 standard? To me this feels like Cordova would be defining what an app 'is'. That's fine for PhoneGap or Chrome apps but not necessarily for Cordova, at least the way I view the project. Agree with all points of Michal except: (1) We already have plugin's which support dependencies https://issues.apache.org/jira/browse/CB-4714 Dependencies imply those plugins are 'required', that's not the same use case as an alias which just expands to a bunch of plugin names. An alias would make it easy to add plugins with 'no deps' attached. I would see this as part of the plugin repository discovery. Maybe people could register their own 'aliases': plugin add @cordova-stuff plugin add @chrome-stuff plugin add @phonegap-stuff
Re: When to do Official Apache Releases
I don't see why we would ship anything other than the native platforms and docs in an official Apache release. We use those from the more frequently shipped CI, and plugins it just makes good sense to stay on top of now that we have a semblance of dependency management in Cordova. On Tue, Sep 3, 2013 at 9:36 AM, Andrew Grieve agri...@chromium.org wrote: It's been mentioned before, but with CLI, there's not a lot of utility in doing official apache releases (uploading signed zips to dist.apache.org). I don't think we should stop doing these entirely, but should we still do these for each Cadence Release? An alternative would be to do them only once / twice a year. Any thoughts on why / why not? Andrew
Re: Cutting down on size of docs
go for it, says I On Tue, Sep 3, 2013 at 7:19 AM, Andrew Grieve agri...@chromium.org wrote: Anyone opposed if I delete the old rc versions of docs (e.g. ite/public/docs/en/1.9.0rc1) They bloat the repo and I don't think add any value.
Re: Frequency of releases
I like it, but I would stress that this is at most once per week, not necessarily every week. It should be fine to just skip a week if nothing interesting landed. On Tue, Sep 3, 2013 at 12:30 PM, Andrew Grieve agri...@chromium.org wrote: We talked a bit about how frequent to release plugins / plugman / cli during the hangout, but want to have a list discussion about it. Some points to think about: - It's convenient to be able to release at any time (get immediate feedback) - Users may get annoyed if we update too frequently (update once a day is annoying) - Batching releases will make release announcement blog posts feasible (same as last point) Right now, I've put on the wiki that: CLI, Plugman: Releases happen on Tuesdays Core Plugins: Releases happen on Wednesdays https://wiki.apache.org/cordova/VersioningAndReleaseStrategy I chose arbitrarily, so now's the time to actually discuss what would be good here. Note that this is only for feature releases, and that emergency patch releases can still be done at any time. I'm now thinking that it would be nice to release both CLI/plugman and plugins on the same day, and combine the blog post for them. Instead of having an explicit release announcement blog post, we can have a Last week in Cordova post similar to http://peter.sh/category/last-week/. Thoughts?
Re: Frequency of releases
Yup, agree w/ you both. I suspect we will see the releases slow w/ time for both plugins and the CI. (Hope, maybe?) On Tue, Sep 3, 2013 at 9:57 AM, Michal Mocny mmo...@chromium.org wrote: I like it, but I would stress that this is at most once per week, not necessarily every week. It should be fine to just skip a week if nothing interesting landed. On Tue, Sep 3, 2013 at 12:30 PM, Andrew Grieve agri...@chromium.org wrote: We talked a bit about how frequent to release plugins / plugman / cli during the hangout, but want to have a list discussion about it. Some points to think about: - It's convenient to be able to release at any time (get immediate feedback) - Users may get annoyed if we update too frequently (update once a day is annoying) - Batching releases will make release announcement blog posts feasible (same as last point) Right now, I've put on the wiki that: CLI, Plugman: Releases happen on Tuesdays Core Plugins: Releases happen on Wednesdays https://wiki.apache.org/cordova/VersioningAndReleaseStrategy I chose arbitrarily, so now's the time to actually discuss what would be good here. Note that this is only for feature releases, and that emergency patch releases can still be done at any time. I'm now thinking that it would be nice to release both CLI/plugman and plugins on the same day, and combine the blog post for them. Instead of having an explicit release announcement blog post, we can have a Last week in Cordova post similar to http://peter.sh/category/last-week/. Thoughts?
Re: tagging on plugman / cli
If I understand correct, these tags aren't going to be used by npm, just make it easier for us to map npm releases to git hash's? Sounds fine, but hoping these stay well lined up over time. On Tue, Sep 3, 2013 at 12:33 PM, Andrew Grieve agri...@chromium.org wrote: Right now CLI plugman don't have git tags associated with their npm releases. I'd like to be able to do a git log latest..master in order to enumerate changes since the last release. So, I'd like to propose: #1 - Add a git tag for each npm release, where the tag name is the same as the version #2 - Add a git tag called latest, which points to the most recent release I've added this already to https://wiki.apache.org/cordova/StepsForToolsRelease, but wanted explicit buy-in here. #1 will result in a lot of tags being created over time (which I think is fine). Andrew
Re: cli plugins 'alias'?
Or you could create cordova-plugin-core, cordova-plugin-chromeos, and cordova-plugin-phonegap repos, with a plugin.xml that have the dependencies you describe to achieve the same result. As the other guys mentoin, there's many ways to do this now without adding a new feature which is the most pragmatic approach. (This will be dramatically easier and more obvious once http://plugins.cordova.io ships at the end of hte month.) On Tue, Sep 3, 2013 at 9:57 AM, jbo...@openmv.com jbo...@openmv.com wrote: On Tue Sep 3 10:47 AM, Braden Shepherdson wrote: Agreed with Michal. There's actually a third option coming too: we want apps to be able to name dependencies. So you should be able to copy in the mobile- spec app, then `cordova plugin add` or whatever the syntax becomes, and it will install all of the app's dependencies. I'm less a fan of 'app dependencies', lots of frameworks and ways of thinking about how to organize an application. Is this a W3C, HTML5 standard? To me this feels like Cordova would be defining what an app 'is'. That's fine for PhoneGap or Chrome apps but not necessarily for Cordova, at least the way I view the project. Agree with all points of Michal except: (1) We already have plugin's which support dependencies https://issues.apache.org/jira/browse/CB-4714 Dependencies imply those plugins are 'required', that's not the same use case as an alias which just expands to a bunch of plugin names. An alias would make it easy to add plugins with 'no deps' attached. I would see this as part of the plugin repository discovery. Maybe people could register their own 'aliases': plugin add @cordova-stuff plugin add @chrome-stuff plugin add @phonegap-stuff
Re: Releases in a 3.0 World
Tools release process looks good to me, but I've not done some parts of that process before. Braden On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny mmo...@chromium.org wrote: For Strategy page: RE: Weekly Releases -- do we skip a release if there is nothing significant to push, or do we release so long as there is at least one patch? RE: Cadence Releases -- These releases include: platform repos, cordova-js, mobile-spec, cordova-docs, cordova-cli, cordova-plugman -- clarifying that include for the sem-ver projects means only packaging into a zip/tarball, not that we bump versions numbers during a cadence release? Or do we bump sem-ver as well? == For plugin release page: # Edit version within plugin.xml based off of changes. --- this means deduce the semantic effect on version right? IE, is it a major/minor/point release? Generally, how do we prevent changes from sneaking in to core plugins during the time it takes release master to make the changes? The release master has to commit back to Changelog. Perhaps he/she makes that change directly on master, and we rebase that change back into dev after the release? That way, we don't read from dev branch once a release process is started. For each plugin that had unreleased commits .. increment the micro -- why? TEST section -- suggest adding a not to the top of the guide so that you create mobile-spec BEFORE starting the release. This way, you create a project with the old versions of plugins more easily. == Generally these looks really good (haven't finished reading Cadence release doc yet, will comment on that soon). However, while I love the code snippets for suggested commands, some of them look like they wouldn't work if you copypaste them. Perhaps we should go through the docs on the next release and make it clear which are verbatim commands and which are just documentation-with-code. On Tue, Sep 3, 2013 at 12:18 PM, Andrew Grieve agri...@chromium.org wrote: Finally finished updating the wiki's instructions to follow this proposal. Summary of changes: https://wiki.apache.org/cordova/VersioningAndReleaseStrategy - Explains our versioning strategy (SemVer vs CadVer) https://wiki.apache.org/cordova/CommitterWorkflow - Extracted Pull Requst Processing into its own page ( ProcessingPullRequests https://wiki.apache.org/cordova/ProcessingPullRequests ) - Added a Which Branch to Commit To section - Minor tweaks to commit process: - Mention `git rebase origin/master -i` - Marked some steps as optional - Linked to post-review (rbtools) install page - Made it more explicit that you should test commits you patch in https://wiki.apache.org/cordova/StepsForPluginRelease - Process to go through to update core plugins https://wiki.apache.org/cordova/StepsForToolsRelease - Process to go through to update plugman / CLI https://wiki.apache.org/cordova/CuttingReleases - Made it clear that it applies to Cadence Releases - Expanded What to test section - Added releasing of CLI to the steps - Moved Official Apache Releases to the bottom To all steps release steps pages, I've added an Update CHANGELOG.md step. iOS has done this forever, but I think all repos should do it. Would love if these pages could be read by all committers. Especially the StepsForToolsRelease page, as I've never done a tools release (and so was somewhat guessing). Another part I'm unsure of is where the mapping to platform repo versions is within CLI. There are still some points to discuss, which I will send separate emails about :) On Sun, Aug 18, 2013 at 11:30 PM, Ian Clelland iclell...@google.com wrote: On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve agri...@chromium.org wrote: After the discussion on the group hangout + some sleeping, I think we're ready for a proposal... So here it is! - It does *not* propose any changes to our Deprecation policy. That's for another thread (which I'll get to on Monday if no one else does) :) - It does not contain how we store version numbers. That's covered here: http://wiki.apache.org/cordova/StoringRepoVersionsDesign Once we get to a consensus, I'll transfer this to the wiki. Please review comment! There are two kinds of versions: 1. SemVer (www.semver.org) - Used by platforms, plugman, cli 2. CadVer (just made that up :P Cadence Version) - Used by cli, mobile-spec, cordova-js I like this, as it separates the fast-moving, feature-based semantic version of any given component from the API level, and interoperability promises, of the Cadence Version. What, then, is the granularity of the Cadence Version intended to be? Is is the 3 in Cordova 3.0, and will stay at 3 until it hits 4 next year? (Or, just as descriptively, we can say that it is at
Re: When to update version numbers?
+1 for #2. On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny mmo...@chromium.org wrote: +1 for option #2 On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve agri...@chromium.org wrote: For repos that use SemVer, there are two options: 1. Update the version number at the time that the change is made 2. Update the version number only when doing a release. Right now, #2 is what I've put in the wiki instructions, but it can be changed of course :) Two main reasons I think #2 will work better: - #1 might be too complicated (might forget to update it, may update the version multiple times if multiple feature changes go in) - #2 If doing a release, you should know what you're releasing. Having to choose the right version number will force you to understand what you're releasing.
Re: tagging on plugman / cli
we should encourage `npm version` as the method to ensure things stay in sync (run `npm help version` to see what I'm talking about) On Tue, Sep 3, 2013 at 10:00 AM, Michal Mocny mmo...@chromium.org wrote: If I understand correct, these tags aren't going to be used by npm, just make it easier for us to map npm releases to git hash's? Sounds fine, but hoping these stay well lined up over time. On Tue, Sep 3, 2013 at 12:33 PM, Andrew Grieve agri...@chromium.org wrote: Right now CLI plugman don't have git tags associated with their npm releases. I'd like to be able to do a git log latest..master in order to enumerate changes since the last release. So, I'd like to propose: #1 - Add a git tag for each npm release, where the tag name is the same as the version #2 - Add a git tag called latest, which points to the most recent release I've added this already to https://wiki.apache.org/cordova/StepsForToolsRelease, but wanted explicit buy-in here. #1 will result in a lot of tags being created over time (which I think is fine). Andrew
Re: Frequency of releases
Agreed, I think this works. I share the hope that the frequency will drop. Though it looks again this year like the new iOS version is going to cause us some suffering. Braden On Tue, Sep 3, 2013 at 1:06 PM, Brian LeRoux b...@brian.io wrote: Yup, agree w/ you both. I suspect we will see the releases slow w/ time for both plugins and the CI. (Hope, maybe?) On Tue, Sep 3, 2013 at 9:57 AM, Michal Mocny mmo...@chromium.org wrote: I like it, but I would stress that this is at most once per week, not necessarily every week. It should be fine to just skip a week if nothing interesting landed. On Tue, Sep 3, 2013 at 12:30 PM, Andrew Grieve agri...@chromium.org wrote: We talked a bit about how frequent to release plugins / plugman / cli during the hangout, but want to have a list discussion about it. Some points to think about: - It's convenient to be able to release at any time (get immediate feedback) - Users may get annoyed if we update too frequently (update once a day is annoying) - Batching releases will make release announcement blog posts feasible (same as last point) Right now, I've put on the wiki that: CLI, Plugman: Releases happen on Tuesdays Core Plugins: Releases happen on Wednesdays https://wiki.apache.org/cordova/VersioningAndReleaseStrategy I chose arbitrarily, so now's the time to actually discuss what would be good here. Note that this is only for feature releases, and that emergency patch releases can still be done at any time. I'm now thinking that it would be nice to release both CLI/plugman and plugins on the same day, and combine the blog post for them. Instead of having an explicit release announcement blog post, we can have a Last week in Cordova post similar to http://peter.sh/category/last-week/. Thoughts?
Re: tagging on plugman / cli
Ooh, I didn't know about that command. I agree that it's a good way to go... except that the wonky version numbers of the tools (3.0.0-0.10.2) might make that impossible. Or is that valid semver? On Tue, Sep 3, 2013 at 1:10 PM, Brian LeRoux b...@brian.io wrote: we should encourage `npm version` as the method to ensure things stay in sync (run `npm help version` to see what I'm talking about) On Tue, Sep 3, 2013 at 10:00 AM, Michal Mocny mmo...@chromium.org wrote: If I understand correct, these tags aren't going to be used by npm, just make it easier for us to map npm releases to git hash's? Sounds fine, but hoping these stay well lined up over time. On Tue, Sep 3, 2013 at 12:33 PM, Andrew Grieve agri...@chromium.org wrote: Right now CLI plugman don't have git tags associated with their npm releases. I'd like to be able to do a git log latest..master in order to enumerate changes since the last release. So, I'd like to propose: #1 - Add a git tag for each npm release, where the tag name is the same as the version #2 - Add a git tag called latest, which points to the most recent release I've added this already to https://wiki.apache.org/cordova/StepsForToolsRelease, but wanted explicit buy-in here. #1 will result in a lot of tags being created over time (which I think is fine). Andrew
Re: Releases in a 3.0 World
For Strategy page: RE: Weekly Releases -- do we skip a release if there is nothing significant to push, or do we release so long as there is at least one patch? RE: Cadence Releases -- These releases include: platform repos, cordova-js, mobile-spec, cordova-docs, cordova-cli, cordova-plugman -- clarifying that include for the sem-ver projects means only packaging into a zip/tarball, not that we bump versions numbers during a cadence release? Or do we bump sem-ver as well? == For plugin release page: # Edit version within plugin.xml based off of changes. --- this means deduce the semantic effect on version right? IE, is it a major/minor/point release? Generally, how do we prevent changes from sneaking in to core plugins during the time it takes release master to make the changes? The release master has to commit back to Changelog. Perhaps he/she makes that change directly on master, and we rebase that change back into dev after the release? That way, we don't read from dev branch once a release process is started. For each plugin that had unreleased commits .. increment the micro -- why? TEST section -- suggest adding a not to the top of the guide so that you create mobile-spec BEFORE starting the release. This way, you create a project with the old versions of plugins more easily. == Generally these looks really good (haven't finished reading Cadence release doc yet, will comment on that soon). However, while I love the code snippets for suggested commands, some of them look like they wouldn't work if you copypaste them. Perhaps we should go through the docs on the next release and make it clear which are verbatim commands and which are just documentation-with-code. On Tue, Sep 3, 2013 at 12:18 PM, Andrew Grieve agri...@chromium.org wrote: Finally finished updating the wiki's instructions to follow this proposal. Summary of changes: https://wiki.apache.org/cordova/VersioningAndReleaseStrategy - Explains our versioning strategy (SemVer vs CadVer) https://wiki.apache.org/cordova/CommitterWorkflow - Extracted Pull Requst Processing into its own page ( ProcessingPullRequests https://wiki.apache.org/cordova/ProcessingPullRequests ) - Added a Which Branch to Commit To section - Minor tweaks to commit process: - Mention `git rebase origin/master -i` - Marked some steps as optional - Linked to post-review (rbtools) install page - Made it more explicit that you should test commits you patch in https://wiki.apache.org/cordova/StepsForPluginRelease - Process to go through to update core plugins https://wiki.apache.org/cordova/StepsForToolsRelease - Process to go through to update plugman / CLI https://wiki.apache.org/cordova/CuttingReleases - Made it clear that it applies to Cadence Releases - Expanded What to test section - Added releasing of CLI to the steps - Moved Official Apache Releases to the bottom To all steps release steps pages, I've added an Update CHANGELOG.md step. iOS has done this forever, but I think all repos should do it. Would love if these pages could be read by all committers. Especially the StepsForToolsRelease page, as I've never done a tools release (and so was somewhat guessing). Another part I'm unsure of is where the mapping to platform repo versions is within CLI. There are still some points to discuss, which I will send separate emails about :) On Sun, Aug 18, 2013 at 11:30 PM, Ian Clelland iclell...@google.com wrote: On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve agri...@chromium.org wrote: After the discussion on the group hangout + some sleeping, I think we're ready for a proposal... So here it is! - It does *not* propose any changes to our Deprecation policy. That's for another thread (which I'll get to on Monday if no one else does) :) - It does not contain how we store version numbers. That's covered here: http://wiki.apache.org/cordova/StoringRepoVersionsDesign Once we get to a consensus, I'll transfer this to the wiki. Please review comment! There are two kinds of versions: 1. SemVer (www.semver.org) - Used by platforms, plugman, cli 2. CadVer (just made that up :P Cadence Version) - Used by cli, mobile-spec, cordova-js I like this, as it separates the fast-moving, feature-based semantic version of any given component from the API level, and interoperability promises, of the Cadence Version. What, then, is the granularity of the Cadence Version intended to be? Is is the 3 in Cordova 3.0, and will stay at 3 until it hits 4 next year? (Or, just as descriptively, we can say that it is at Cordova Fancy-Pants now, and eventually progress to Cordova Enraged-Wombat) Or is it going to have major and minor components as well, and advance roughly monthly, as before? There are two kinds of releases: 1. Patch releases - Pretty much any repo can release a patch
Re: Frequency of releases
I like it - for clarity - I also think that the CLI and plugman should be on the same day On Tue, Sep 3, 2013 at 1:12 PM, Braden Shepherdson bra...@chromium.orgwrote: Agreed, I think this works. I share the hope that the frequency will drop. Though it looks again this year like the new iOS version is going to cause us some suffering. Braden On Tue, Sep 3, 2013 at 1:06 PM, Brian LeRoux b...@brian.io wrote: Yup, agree w/ you both. I suspect we will see the releases slow w/ time for both plugins and the CI. (Hope, maybe?) On Tue, Sep 3, 2013 at 9:57 AM, Michal Mocny mmo...@chromium.org wrote: I like it, but I would stress that this is at most once per week, not necessarily every week. It should be fine to just skip a week if nothing interesting landed. On Tue, Sep 3, 2013 at 12:30 PM, Andrew Grieve agri...@chromium.org wrote: We talked a bit about how frequent to release plugins / plugman / cli during the hangout, but want to have a list discussion about it. Some points to think about: - It's convenient to be able to release at any time (get immediate feedback) - Users may get annoyed if we update too frequently (update once a day is annoying) - Batching releases will make release announcement blog posts feasible (same as last point) Right now, I've put on the wiki that: CLI, Plugman: Releases happen on Tuesdays Core Plugins: Releases happen on Wednesdays https://wiki.apache.org/cordova/VersioningAndReleaseStrategy I chose arbitrarily, so now's the time to actually discuss what would be good here. Note that this is only for feature releases, and that emergency patch releases can still be done at any time. I'm now thinking that it would be nice to release both CLI/plugman and plugins on the same day, and combine the blog post for them. Instead of having an explicit release announcement blog post, we can have a Last week in Cordova post similar to http://peter.sh/category/last-week/ . Thoughts?
Re: When to update version numbers?
+1 for #2 as well On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson bra...@chromium.orgwrote: +1 for #2. On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny mmo...@chromium.org wrote: +1 for option #2 On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve agri...@chromium.org wrote: For repos that use SemVer, there are two options: 1. Update the version number at the time that the change is made 2. Update the version number only when doing a release. Right now, #2 is what I've put in the wiki instructions, but it can be changed of course :) Two main reasons I think #2 will work better: - #1 might be too complicated (might forget to update it, may update the version multiple times if multiple feature changes go in) - #2 If doing a release, you should know what you're releasing. Having to choose the right version number will force you to understand what you're releasing.
Release Masters Component Leads
I brought up this idea before (http://markmail.org/thread/75fv4ru7rd4vwrrb), it was well received I think, but never made its way to our CuttingReleases page. I'd like to move forward with formally introducing this concept on our wiki page. Component Lead: - For each release, each repo has a Component Lead - They perform release steps and signs off on a component (ios, android, etc). Release Master: - Delegate release tasks - Communicate release status - Nag people responsible for unfinished tasks Sound good? Motivation behind making a single person the release master for a release: - To ensure that steps actually get done by ensuring each task has an owner - Improve coordination communication during releases Before I go and add this to the release wiki pages though: - What should the process be for choosing the release master / component lead? - Have a rotation? - Ask for volunteer each time? Any other thoughts along the matter?
Re: tagging on plugman / cli
Neat. Just tried it out: $ npm version 3.1.0-0.8.0-dev v3.1.0-0.8.0-dev $ git tag -l ... v3.1.0-0.8.0-dev So, it's similar to what we have for other repos, except it adds a v prefix. The prefix seems useful I think. On Tue, Sep 3, 2013 at 1:14 PM, Braden Shepherdson bra...@chromium.orgwrote: Ooh, I didn't know about that command. I agree that it's a good way to go... except that the wonky version numbers of the tools (3.0.0-0.10.2) might make that impossible. Or is that valid semver? On Tue, Sep 3, 2013 at 1:10 PM, Brian LeRoux b...@brian.io wrote: we should encourage `npm version` as the method to ensure things stay in sync (run `npm help version` to see what I'm talking about) On Tue, Sep 3, 2013 at 10:00 AM, Michal Mocny mmo...@chromium.org wrote: If I understand correct, these tags aren't going to be used by npm, just make it easier for us to map npm releases to git hash's? Sounds fine, but hoping these stay well lined up over time. On Tue, Sep 3, 2013 at 12:33 PM, Andrew Grieve agri...@chromium.org wrote: Right now CLI plugman don't have git tags associated with their npm releases. I'd like to be able to do a git log latest..master in order to enumerate changes since the last release. So, I'd like to propose: #1 - Add a git tag for each npm release, where the tag name is the same as the version #2 - Add a git tag called latest, which points to the most recent release I've added this already to https://wiki.apache.org/cordova/StepsForToolsRelease, but wanted explicit buy-in here. #1 will result in a lot of tags being created over time (which I think is fine). Andrew
Re: Serve vs. opening an HTML file in the browser
No go. I mean the command ran of course, but upon opening it up in my browser, I got the same. On 9/3/13 12:30 PM, Gord Tanner gtan...@gmail.com wrote: You will need to run: ripple emulate --path /path/to/cordova/project/platform/android/assets/www Let me know if that works for you. On Tue, Sep 3, 2013 at 12:27 PM, Ray Camden rayca...@adobe.com wrote: Ok, I forgot to run cordova serve. I did, and then I get the same behavior as before. A prompt and then infinite console.log messages. On 9/2/13 8:32 PM, Gord Tanner gtan...@gmail.com wrote: Good news! I have a branch that is booting projects made with cordova 3.0 [1]. It is basically a stripped down platform and I tested it booting a project with android and ios.
Frequency of releases
We talked a bit about how frequent to release plugins / plugman / cli during the hangout, but want to have a list discussion about it. Some points to think about: - It's convenient to be able to release at any time (get immediate feedback) - Users may get annoyed if we update too frequently (update once a day is annoying) - Batching releases will make release announcement blog posts feasible (same as last point) Right now, I've put on the wiki that: CLI, Plugman: Releases happen on Tuesdays Core Plugins: Releases happen on Wednesdays https://wiki.apache.org/cordova/VersioningAndReleaseStrategy I chose arbitrarily, so now's the time to actually discuss what would be good here. Note that this is only for feature releases, and that emergency patch releases can still be done at any time. I'm now thinking that it would be nice to release both CLI/plugman and plugins on the same day, and combine the blog post for them. Instead of having an explicit release announcement blog post, we can have a Last week in Cordova post similar to http://peter.sh/category/last-week/. Thoughts?
Re: lib-file for Android, plugman crash
Hi, could a committer please look at this pull request and maybe merge it into master if ok? thanks Axel https://github.com/apache/cordova-plugman/pull/19 https://issues.apache.org/jira/browse/CB-4430#comment-13749605 2013/9/2 Shazron shaz...@gmail.com I believe your iCLA has been received. You are listed here already: http://people.apache.org/committer-index.html#unlistedclas On Mon, Sep 2, 2013 at 1:36 PM, Axel Nennker ignisvul...@gmail.com wrote: Hi Filip Did you get the icla? Best Axel Am 27.08.2013 17:14 schrieb Filip Maj maj@gmail.com: Have you signed and sent in an Apache ICLA? On 2013-08-27 8:10 AM, Axel Nennker ignisvul...@gmail.com wrote: You'r welcome. How does this go forward? There are more things I would fix after this is merged.
Re: Frequency of releases
+1 On Tue, Sep 3, 2013 at 10:22 AM, David Kemp drk...@google.com wrote: I like it - for clarity - I also think that the CLI and plugman should be on the same day On Tue, Sep 3, 2013 at 1:12 PM, Braden Shepherdson bra...@chromium.orgwrote: Agreed, I think this works. I share the hope that the frequency will drop. Though it looks again this year like the new iOS version is going to cause us some suffering. Braden On Tue, Sep 3, 2013 at 1:06 PM, Brian LeRoux b...@brian.io wrote: Yup, agree w/ you both. I suspect we will see the releases slow w/ time for both plugins and the CI. (Hope, maybe?) On Tue, Sep 3, 2013 at 9:57 AM, Michal Mocny mmo...@chromium.org wrote: I like it, but I would stress that this is at most once per week, not necessarily every week. It should be fine to just skip a week if nothing interesting landed. On Tue, Sep 3, 2013 at 12:30 PM, Andrew Grieve agri...@chromium.org wrote: We talked a bit about how frequent to release plugins / plugman / cli during the hangout, but want to have a list discussion about it. Some points to think about: - It's convenient to be able to release at any time (get immediate feedback) - Users may get annoyed if we update too frequently (update once a day is annoying) - Batching releases will make release announcement blog posts feasible (same as last point) Right now, I've put on the wiki that: CLI, Plugman: Releases happen on Tuesdays Core Plugins: Releases happen on Wednesdays https://wiki.apache.org/cordova/VersioningAndReleaseStrategy I chose arbitrarily, so now's the time to actually discuss what would be good here. Note that this is only for feature releases, and that emergency patch releases can still be done at any time. I'm now thinking that it would be nice to release both CLI/plugman and plugins on the same day, and combine the blog post for them. Instead of having an explicit release announcement blog post, we can have a Last week in Cordova post similar to http://peter.sh/category/last-week/ . Thoughts?
Re: When to update version numbers?
+1 for number 2 On Tue, Sep 3, 2013 at 10:16 AM, David Kemp drk...@google.com wrote: +1 for #2 as well On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson bra...@chromium.orgwrote: +1 for #2. On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny mmo...@chromium.org wrote: +1 for option #2 On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve agri...@chromium.org wrote: For repos that use SemVer, there are two options: 1. Update the version number at the time that the change is made 2. Update the version number only when doing a release. Right now, #2 is what I've put in the wiki instructions, but it can be changed of course :) Two main reasons I think #2 will work better: - #1 might be too complicated (might forget to update it, may update the version multiple times if multiple feature changes go in) - #2 If doing a release, you should know what you're releasing. Having to choose the right version number will force you to understand what you're releasing.
RE: cli plugins 'alias'?
On Tue Sep 3 01:09 PM, Brian LeRoux wrote: Or you could create cordova-plugin-core, cordova-plugin-chromeos, and cordova-plugin-phonegap repos, with a plugin.xml that have the dependencies you describe to achieve the same result. As the other guys mentoin, there's many ways to do this now without adding a new feature which is the most pragmatic approach. (This will be dramatically easier and more obvious once http://plugins.cordova.io ships at the end of hte month.) Sounds good to wait and see, might be ok to just distinguish required vs. non-required dependency id=org.apache.cordova.test.echo url=https://github.com/jbondc/cordova-labs.git; subdir=cordova-plugin-echo required=false /
Re: cli plugins 'alias'?
On Tue, Sep 3, 2013 at 10:09 AM, Brian LeRoux b...@brian.io wrote: Or you could create cordova-plugin-core, cordova-plugin-chromeos, and cordova-plugin-phonegap repos, with a plugin.xml that have the dependencies you describe to achieve the same result. As the other guys mentoin, there's many ways to do this now without adding a new feature which is the most pragmatic approach. (This will be dramatically easier and more obvious once http://plugins.cordova.io ships at the end of hte month.) +1
Re: Serve vs. opening an HTML file in the browser
You will need to run: ripple emulate --path /path/to/cordova/project/platform/android/assets/www Let me know if that works for you. On Tue, Sep 3, 2013 at 12:27 PM, Ray Camden rayca...@adobe.com wrote: Ok, I forgot to run cordova serve. I did, and then I get the same behavior as before. A prompt and then infinite console.log messages. On 9/2/13 8:32 PM, Gord Tanner gtan...@gmail.com wrote: Good news! I have a branch that is booting projects made with cordova 3.0 [1]. It is basically a stripped down platform and I tested it booting a project with android and ios. To run: cordova create Baz cordova platform add android cordova prepare ripple emulate (make sure you pick cordova 3.0.0) I was noticing that when I ran cordova serve android it wouldn't have the cordova_plugins.js file. Next Steps: - audit API's that are emulated and ensure they are up to spec (most are just using the 2.0 emulated versions) - reintegrate with cordova cli. Let me know if you take this for a test drive and have any problems. Gord
Re: Release Masters Component Leads
Volunteer maps well to hows its been done implicitly. If you cannot take a given week, find a sensible replacement. Rotation among willing folks makes some sense in terms of passing down of knowledge. -Michal On Tue, Sep 3, 2013 at 12:51 PM, Andrew Grieve agri...@chromium.org wrote: I brought up this idea before (http://markmail.org/thread/75fv4ru7rd4vwrrb ), it was well received I think, but never made its way to our CuttingReleases page. I'd like to move forward with formally introducing this concept on our wiki page. Component Lead: - For each release, each repo has a Component Lead - They perform release steps and signs off on a component (ios, android, etc). Release Master: - Delegate release tasks - Communicate release status - Nag people responsible for unfinished tasks Sound good? Motivation behind making a single person the release master for a release: - To ensure that steps actually get done by ensuring each task has an owner - Improve coordination communication during releases Before I go and add this to the release wiki pages though: - What should the process be for choosing the release master / component lead? - Have a rotation? - Ask for volunteer each time? Any other thoughts along the matter?
Re: When to update version numbers?
+1 for #2 On Tue, Sep 3, 2013 at 11:38 AM, Anis KADRI anis.ka...@gmail.com wrote: +1 for number 2 On Tue, Sep 3, 2013 at 10:16 AM, David Kemp drk...@google.com wrote: +1 for #2 as well On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson bra...@chromium.orgwrote: +1 for #2. On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny mmo...@chromium.org wrote: +1 for option #2 On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve agri...@chromium.org wrote: For repos that use SemVer, there are two options: 1. Update the version number at the time that the change is made 2. Update the version number only when doing a release. Right now, #2 is what I've put in the wiki instructions, but it can be changed of course :) Two main reasons I think #2 will work better: - #1 might be too complicated (might forget to update it, may update the version multiple times if multiple feature changes go in) - #2 If doing a release, you should know what you're releasing. Having to choose the right version number will force you to understand what you're releasing.
Re: What's your daily workflow for cordova development?
This would be my ideal workflow $ cordova plugin add /path/to/plugin $ cordova plugin watch /path/to/plugin # detects if plugin is installed (otherwise fails), watches for changes and automatically updates CLIPROJECT/plugins and re-runs prepare. maybe even `add --watch` (CTRL+C to cancel). We don't have to worry about version numbers. We can just watch the filesystem for changes (and there are node packages that do that such as chokidar [1]) I think update/upgrade for plugins and cordova are more for app developers than plugin developers. As far as testing, I think it should be part of the plugin itself and not part of giant test suite (like mobile-spec). Also I remember us talking about giving the freedom to use whatever testing framework they want as long as it spits out a proper test result format. Was it TAP [2]? [1] https://github.com/paulmillr/chokidar [2] http://en.wikipedia.org/wiki/Test_Anything_Protocol On Tue, Sep 3, 2013 at 8:50 AM, Braden Shepherdson bra...@chromium.org wrote: Responses inline. On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron jbo...@gdesolutions.com wrote: On Mon Sep 2 07:34 PM, Brian LeRoux wrote: Here's a shot. Ideal flow tomorrow might be to generate a plugin called, lets say, Echo that matches something we'd find in our docs, automate add/remove with some sort of watch command. That way ppl are writing to the plugin spec from the beginning instead of refactoring a plugin out of a native project. Thoughts? Two new features could be useful from cli: a) Create an initial plugin from a template cordova plugin create [path] [name] e.g. cordova plugin create F:/GitHub/MyPlugin MyPlugin I agree, this would be useful. It's pretty easy to implement, just not a high priority. Do you want to file a JIRA ticket for it? b) Update all plugins from a cordova application cordova plugins update e.g. cordova create F:/CordovaApp cd F:/CordovaApp cordova plugin add F:/GitHub/MyPlugin cordova plugins update The implementation is likely tricky, how to detect plugin modification? Version check? I image it would remove install the new plugin. cordova plugins update -local Could be useful to force the removal and reinstall of only local plugins (from a filesystem path) / under development... There are plans for an cordova plugin upgrade [foo] command, but you're correct that it's tricky, how we handle dependencies and so on. I've got a draft of a plan for it, but I haven't finished it and sent it around. I think the ideal solution to the larger problem of in-place-updating plugins would be to have the plugin installation logic running on every prepare (and then a cordova watch command that re-runs prepare when the plugins change). My ideal flow is: - I add the plugin via symlink, so that it's pointing to the same place on disk. - I change some file, native or JS or even plugin.xml - cordova watch notices that and re-runs prepare, which updates everything properly. But that takes some doing: what if I removed or renamed a native file? It needs to know which one so that it can be removed, but for that it needs to cache the old plugin.xml, etc. etc. All of these are solvable problems, but it will be some time before all the pieces are in place for this flow. Ultimately, we need to optimize first for app developers, and then for plugin developers. On the other hand, the fact that we're now concerned with the latter suggests that the main app developer flow is pretty solid, which I think it is. With the exception of how painful it currently is to update a platform (rather than a plugin), but we've got plans under discussion for that problem too. I haven't gotten around to running .spec tests but something simple as: c) Running tests within plugin directory cd F:/GitHub/MyPlugin cordova plugin test [Test #1] Passed [Test #2] Failed: Reference error foo doesn't not exist Would be very useful. We want some kind of per-plugin testing story, rather than our big mobile-spec test suite. There are enough problems and questions here, though, that we've just left things as they are for now. That is, one monolithic mobile-spec for all of Cordova's core plugins, and plugin authors are on their own - which generally means that third-party plugins have no tests :( Braden
Re: cli plugins 'alias'?
I think we've had that feature request before (specifically referring to iOS console Logger plugin, being an optional dependency of the platform). I don't think its been implemented, and I cannot find a JIRA issue, so filed: CB-4735 -Michal On Tue, Sep 3, 2013 at 2:56 PM, Jonathan Bond-Caron jbo...@gdesolutions.com wrote: On Tue Sep 3 01:09 PM, Brian LeRoux wrote: Or you could create cordova-plugin-core, cordova-plugin-chromeos, and cordova-plugin-phonegap repos, with a plugin.xml that have the dependencies you describe to achieve the same result. As the other guys mentoin, there's many ways to do this now without adding a new feature which is the most pragmatic approach. (This will be dramatically easier and more obvious once http://plugins.cordova.io ships at the end of hte month.) Sounds good to wait and see, might be ok to just distinguish required vs. non-required dependency id=org.apache.cordova.test.echo url= https://github.com/jbondc/cordova-labs.git; subdir=cordova-plugin-echo required=false /
Re: New iOS 7 UI and backwards compatibility
Shaz, can you test this fix? (I haven't gotten on the 4.5 bandwagon yet)
On Tue, Sep 3, 2013 at 10:59 AM, PJ Dillon p...@sulia.com wrote:
For our purposes, CDVSplashScreen.m (as of 2.9.0) just needed a test for
the OS version when calculating the image bounds:
diff --git a/CordovaLib/Classes/CDVSplashScreen.m
b/CordovaLib/Classes/CDVSplashScreen.m
index fdb79fa..809ce35 100644
--- a/CordovaLib/Classes/CDVSplashScreen.m
+++ b/CordovaLib/Classes/CDVSplashScreen.m
@@ -170,7 +170,9 @@
// There's a special case when the image is the size of the screen.
if (CGSizeEqualToSize(screenSize, imgBounds.size)) {
CGRect statusFrame = [self.viewController.view
convertRect:[UIApplication sharedApplication].statusBarFrame fromView:nil];
-imgBounds.origin.y -= statusFrame.size.height;
+if (floor(NSFoundationVersionNumber) =
NSFoundationVersionNumber_iOS_6_1) {
+imgBounds.origin.y -= statusFrame.size.height;
+}
} else {
CGRect viewBounds = self.viewController.view.bounds;
CGFloat imgAspect = imgBounds.size.width / imgBounds.size.height;
On Tue, Jul 16, 2013 at 11:38 AM, Kerri Shotts kerrisho...@gmail.com
wrote:
Would help if I paid attention to which group things are in... ;) thought
it was in the main forum for some reason (not enough caffeine).
Do file bugs; filing bugs is pretty safe (since how else can devs fix
issues related to iOS7.)
That said, I would still expect the support to be an issue, since
something
could easily break in beta 4. In fact people on the forums have been
complaining about breaks between beta 2 and 3.
Also, do search the forums for the status bar piece (unless that has been
dealt with in 2.9.0/3.0) since there is a really simple line of code you
can add to get back to iOS6 metrics. (Side note: clearly Apple wants us
to
go this new direction, so whether or not PG should even build this in by
default is debatable in my opinion. We all, native and non-native devs
alike have to live in this new world and adjust our UI to reflect what
makes sense here for each app. Perhaps a config.xml setting might be
useful, though, although it should be equally doable in JS/CSS/HTML to do
the required changes. Do note that this is not just a hardship faced by
us:
all native devs are also having to take a hard look at their app and
statistics to see if supporting iOS 6 and 7 is feasible or not, and
judging
from the forum, a large number are going iOS7 only. )
Sent from my phone.
___
Kerri Shotts
photoKandy Studios, LLC
On the Web: http://www.photokandy.com/
Social Media:
Twitter: @photokandy, http://twitter.com/photokandy
Tumblr: http://photokandy.tumblr.com/
Github: https://github.com/kerrishotts
https://github.com/organizations/photokandyStudios
CoderWall: https://coderwall.com/kerrishotts
Apps on the Apple Store:
https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828
Books:
http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book
http://www.packtpub.com/phonegap-social-app-development/book
On Jul 16, 2013, at 10:14, Andrew Grieve agri...@chromium.org wrote:
There have been no splash screen fixes since 2.9.0 that I'm aware of.
Please file a bug on our jira:https://issues.apache.org/jira/browse/CB
On Tue, Jul 16, 2013 at 10:56 AM, PJ Dillon p...@sulia.com wrote:
Hi,
I haven't found any discussion about this searching through my mail. But
the UI is broken in iOS 7. I actually don't know if I'm allowed to
discuss
the details. It's glaringly obvious, though, and it makes compatibility
with iOS 6 somewhat of a chore for cordova-based apps, especially with
the
position splash screen unless I'm mistaken.
So, before I go hacking around with our view controller to accommodate
both
6 7, has this been taken care of already, and I'm just overlooking it?
We're trying to get an app out the door as soon as iOS 7 launches.
Thanks,
PJ Dillon
Sulia, Inc
urlutil.js
Hey I just pulled the latest Cordova JS and I noticed that urlutil has failing tests. What is urlutil for, and why are the tests failing? Should I care about this beyond the fact that I dislike failing tests? Joe
Re: Cutting down on size of docs
Can we get them off the docs website as well? They don't provide much value once the release is officially out. Simon Mac Donald http://hi.im/simonmacdonald On Tue, Sep 3, 2013 at 8:25 PM, Tommy-Carlos Williams to...@devgeeks.org wrote: +1 I think they even actively add confusion. On 04/09/2013, at 2:37 AM, Brian LeRoux b...@brian.io wrote: go for it, says I On Tue, Sep 3, 2013 at 7:19 AM, Andrew Grieve agri...@chromium.org wrote: Anyone opposed if I delete the old rc versions of docs (e.g. ite/public/docs/en/1.9.0rc1) They bloat the repo and I don't think add any value.
Non-Git Plugin Dependencies
We were working on a redistribution of Cordova that included some plugins and ran into a use-case not covered by the current plugin spec.[1] Currently there are two ways to specify a dependency 1. Using a combination of url, commit and subdir which plugman will use to clone down a repo and install 2. Set the url to ., skip the commit and specify a subdir relative to the root of the repo. Plugman then runs git-rev parse to find the root and install from there. I would like to propose a third way which would be relative to the current install and not use git at all 3. Skip the url, skip the commit and specify a subdir relative to the current plugin.xml. This would allow us to distribute a version of cordova with plugins to anyone without an unnecessary requirement on git (considering the plugins are fully installed) 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Non-Git Plugin Dependencies
Sounds reasonable to me. Conceptually, I'm not sure why the syntax for (2) shouldn't do what you request when the url for the original plugin was a local path? Maybe just a bug? -Michal On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz jheif...@blackberry.comwrote: We were working on a redistribution of Cordova that included some plugins and ran into a use-case not covered by the current plugin spec.[1] Currently there are two ways to specify a dependency 1. Using a combination of url, commit and subdir which plugman will use to clone down a repo and install 2. Set the url to ., skip the commit and specify a subdir relative to the root of the repo. Plugman then runs git-rev parse to find the root and install from there. I would like to propose a third way which would be relative to the current install and not use git at all 3. Skip the url, skip the commit and specify a subdir relative to the current plugin.xml. This would allow us to distribute a version of cordova with plugins to anyone without an unnecessary requirement on git (considering the plugins are fully installed) 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Non-Git Plugin Dependencies
Mulling this over a bit, I think I would like a solution for specifying dependancies that would work regardless of where/how the plugins are hosted, git or local. If you had: BB_PLUGINS/ - plug1/ - plug2/ ... (and plug1 depends on plug2), then: cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1..and.. cordova plugin add GIT_REPO:BB_PLUGINS/plug1 ..should both work without changing all of the dependency tags in plug1. Actually, the plugin author should not have an explicit say in how a user manages these directories (except in the directory structure). Note that this situation applies whenever a user clones your plugin repo to locally, or for the reverse direction, when ever they add your plugins into their teams' git repo. Right now, thats not possible, because when installing from local path with url=. there is no way to know which of the plugins parent directories to consider as the root. We could resolve this using several ways, among them: (1) Jeffreys proposal: dropping the url=. means path relative to this plugin (note however, that I propose it also works when installing from a git repo). Deprecate/warn against using url=.. (2) Support a new special file to mark the plugin root dir so we can walk the directory tree to find the valid target for url=. (ie, replace the requirement for a .git with a requirement for a .cordova_repo, which BB and others could place within their plugin bundle). I like (1). -Michal On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny mmo...@chromium.org wrote: Sounds reasonable to me. Conceptually, I'm not sure why the syntax for (2) shouldn't do what you request when the url for the original plugin was a local path? Maybe just a bug? -Michal On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz jheif...@blackberry.comwrote: We were working on a redistribution of Cordova that included some plugins and ran into a use-case not covered by the current plugin spec.[1] Currently there are two ways to specify a dependency 1. Using a combination of url, commit and subdir which plugman will use to clone down a repo and install 2. Set the url to ., skip the commit and specify a subdir relative to the root of the repo. Plugman then runs git-rev parse to find the root and install from there. I would like to propose a third way which would be relative to the current install and not use git at all 3. Skip the url, skip the commit and specify a subdir relative to the current plugin.xml. This would allow us to distribute a version of cordova with plugins to anyone without an unnecessary requirement on git (considering the plugins are fully installed) 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Cutting down on size of docs
Zapped. On Tue, Sep 3, 2013 at 8:37 PM, Simon MacDonald simon.macdon...@gmail.comwrote: Can we get them off the docs website as well? They don't provide much value once the release is officially out. Simon Mac Donald http://hi.im/simonmacdonald On Tue, Sep 3, 2013 at 8:25 PM, Tommy-Carlos Williams to...@devgeeks.org wrote: +1 I think they even actively add confusion. On 04/09/2013, at 2:37 AM, Brian LeRoux b...@brian.io wrote: go for it, says I On Tue, Sep 3, 2013 at 7:19 AM, Andrew Grieve agri...@chromium.org wrote: Anyone opposed if I delete the old rc versions of docs (e.g. ite/public/docs/en/1.9.0rc1) They bloat the repo and I don't think add any value.
Re: Merge plugin dev branchs into master
Just to loop back on this - I've updated the https://wiki.apache.org/cordova/CommitterWorkflow to include a section at the bottom on which branch to commit against. On Thu, Aug 29, 2013 at 4:00 PM, Becky Gibson gibson.be...@gmail.comwrote: Yes, updating the wiki would be helpful. I'd like to submit a fix but since I don't follow this list all this time, I'm not sure if I should be working off of dev or master. Based on the above thread I think dev? thanks, -becky On Thu, Aug 29, 2013 at 11:48 AM, Andrew Grieve agri...@chromium.org wrote: Steve, did you do this? I didn't notice a JIRA issue or blog post. On Fri, Aug 16, 2013 at 10:59 AM, Andrew Grieve agri...@chromium.org wrote: Thought of another step! Generate a changelog, and turn it into a blog post so that people will know about the update :) On Thu, Aug 15, 2013 at 4:59 PM, Steven Gill stevengil...@gmail.com wrote: Thanks for the feedback Andrew! Sounds good to me. I am going to go through these steps today. On Thu, Aug 15, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.org wrote: Great! I agree it's time someone take a stab at this! On Thu, Aug 15, 2013 at 3:00 PM, Steven Gill stevengil...@gmail.com wrote: I want to try and flush out the process for merging the dev branches for the core plugins into master and get it onto the wiki. Currently the dev branches have some readme changes, namespace changes and package changes for android. I don't believe any of these changes should be breaking changes. Process 1. Create issue on jira for running mobile spec tests on all platforms using dev branch of plugins 2. Test on all platforms 3. Merge in change into master 4. Publish to plugins.cordova.io? Do we really need to test the plugins on all the platforms for changes that won't affect them at all? I think no. And we should only test plugins that have changes to them (in this case all of them). Should add in bumping of the version number. I think one thing to add to the process is to create mobilespec with the existing versions of plugins, then `cordova plugin rm` them all, then `cordova plugin add` the new ones using a URL that points to the dev branch. aka, test out the upgrade process.
Re: urlutil.js
likely need to update your node_modules. On Tue, Sep 3, 2013 at 7:25 PM, Joe Bowser bows...@gmail.com wrote: Hey I just pulled the latest Cordova JS and I noticed that urlutil has failing tests. What is urlutil for, and why are the tests failing? Should I care about this beyond the fact that I dislike failing tests? Joe
Re: Non-Git Plugin Dependencies
Agree the use-case is valid. Here's a variation on (1) that I think is marginally nicer: url=. to be made optional, but default value is . subdir= works only with git repos and is always relative to the root of the repo. path= works with git repos or local paths and is relative to the plugin.xml of the current plugin. You can't have url or subdir if you have path. Support was just added for specifying commit and path within url. So, we could actually just deprecate subdir. and have url or path E.g.: url=some/path.git would specify a git URL relative to the current plugin's git url. E.g.: url=#branch2 would specify a branch on the current URL (cordova-labs style) E.g.: url=#branch2:plugins/A would specify a branch on the current URL plus a subdir within it. E.g.: url=#:plugins/A would be invalid. (Use path if you just want to set the path) E.g.: path=../B is always a relative fs path. If the current plugin is from git, then be careful not to go above the git root. On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny mmo...@chromium.org wrote: Mulling this over a bit, I think I would like a solution for specifying dependancies that would work regardless of where/how the plugins are hosted, git or local. If you had: BB_PLUGINS/ - plug1/ - plug2/ ... (and plug1 depends on plug2), then: cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1..and.. cordova plugin add GIT_REPO:BB_PLUGINS/plug1 ..should both work without changing all of the dependency tags in plug1. Actually, the plugin author should not have an explicit say in how a user manages these directories (except in the directory structure). Note that this situation applies whenever a user clones your plugin repo to locally, or for the reverse direction, when ever they add your plugins into their teams' git repo. Right now, thats not possible, because when installing from local path with url=. there is no way to know which of the plugins parent directories to consider as the root. We could resolve this using several ways, among them: (1) Jeffreys proposal: dropping the url=. means path relative to this plugin (note however, that I propose it also works when installing from a git repo). Deprecate/warn against using url=.. (2) Support a new special file to mark the plugin root dir so we can walk the directory tree to find the valid target for url=. (ie, replace the requirement for a .git with a requirement for a .cordova_repo, which BB and others could place within their plugin bundle). I like (1). -Michal On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny mmo...@chromium.org wrote: Sounds reasonable to me. Conceptually, I'm not sure why the syntax for (2) shouldn't do what you request when the url for the original plugin was a local path? Maybe just a bug? -Michal On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz jheif...@blackberry.com wrote: We were working on a redistribution of Cordova that included some plugins and ran into a use-case not covered by the current plugin spec.[1] Currently there are two ways to specify a dependency 1. Using a combination of url, commit and subdir which plugman will use to clone down a repo and install 2. Set the url to ., skip the commit and specify a subdir relative to the root of the repo. Plugman then runs git-rev parse to find the root and install from there. I would like to propose a third way which would be relative to the current install and not use git at all 3. Skip the url, skip the commit and specify a subdir relative to the current plugin.xml. This would allow us to distribute a version of cordova with plugins to anyone without an unnecessary requirement on git (considering the plugins are fully installed) 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Non-Git Plugin Dependencies
If URL can be relative, why do we need a new path parameter? All we would need is to treat leading ./ or ../ as relative to the plugin not root, which I think is fine. I'll sleep on it and draw it out on whiteboard tomorrow to make sure all the cases are handled. On Tue, Sep 3, 2013 at 11:56 PM, Andrew Grieve agri...@chromium.org wrote: Agree the use-case is valid. Here's a variation on (1) that I think is marginally nicer: url=. to be made optional, but default value is . subdir= works only with git repos and is always relative to the root of the repo. path= works with git repos or local paths and is relative to the plugin.xml of the current plugin. You can't have url or subdir if you have path. Support was just added for specifying commit and path within url. So, we could actually just deprecate subdir. and have url or path E.g.: url=some/path.git would specify a git URL relative to the current plugin's git url. E.g.: url=#branch2 would specify a branch on the current URL (cordova-labs style) E.g.: url=#branch2:plugins/A would specify a branch on the current URL plus a subdir within it. E.g.: url=#:plugins/A would be invalid. (Use path if you just want to set the path) E.g.: path=../B is always a relative fs path. If the current plugin is from git, then be careful not to go above the git root. On Tue, Sep 3, 2013 at 10:27 PM, Michal Mocny mmo...@chromium.org wrote: Mulling this over a bit, I think I would like a solution for specifying dependancies that would work regardless of where/how the plugins are hosted, git or local. If you had: BB_PLUGINS/ - plug1/ - plug2/ ... (and plug1 depends on plug2), then: cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1..and.. cordova plugin add GIT_REPO:BB_PLUGINS/plug1 ..should both work without changing all of the dependency tags in plug1. Actually, the plugin author should not have an explicit say in how a user manages these directories (except in the directory structure). Note that this situation applies whenever a user clones your plugin repo to locally, or for the reverse direction, when ever they add your plugins into their teams' git repo. Right now, thats not possible, because when installing from local path with url=. there is no way to know which of the plugins parent directories to consider as the root. We could resolve this using several ways, among them: (1) Jeffreys proposal: dropping the url=. means path relative to this plugin (note however, that I propose it also works when installing from a git repo). Deprecate/warn against using url=.. (2) Support a new special file to mark the plugin root dir so we can walk the directory tree to find the valid target for url=. (ie, replace the requirement for a .git with a requirement for a .cordova_repo, which BB and others could place within their plugin bundle). I like (1). -Michal On Tue, Sep 3, 2013 at 9:54 PM, Michal Mocny mmo...@chromium.org wrote: Sounds reasonable to me. Conceptually, I'm not sure why the syntax for (2) shouldn't do what you request when the url for the original plugin was a local path? Maybe just a bug? -Michal On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz jheif...@blackberry.comwrote: We were working on a redistribution of Cordova that included some plugins and ran into a use-case not covered by the current plugin spec.[1] Currently there are two ways to specify a dependency 1. Using a combination of url, commit and subdir which plugman will use to clone down a repo and install 2. Set the url to ., skip the commit and specify a subdir relative to the root of the repo. Plugman then runs git-rev parse to find the root and install from there. I would like to propose a third way which would be relative to the current install and not use git at all 3. Skip the url, skip the commit and specify a subdir relative to the current plugin.xml. This would allow us to distribute a version of cordova with plugins to anyone without an unnecessary requirement on git (considering the plugins are fully installed) 1. http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
