Re: cordova cli global vs. local install
cd 3.0 npm link . cd .. cordova -v cd 3.1 npm link . cd .. cordova -v Very gruntable @purplecabbage risingj.com On Mon, Sep 9, 2013 at 9:27 PM, Tommy-Carlos Williams to...@devgeeks.orgwrote: Or, we could just drop it... and just write a blog post on how to use a local cordova vs the global one in projects you want to have a specific version (i.e.: some script code example wrapper for a cordova command in ./node_modules/.bin/cordova). 0.o - tommy On 10/09/2013, at 1:42 PM, Michal Mocny mmo...@chromium.org wrote: An alternative to leveraging npm locally may be to split cli/lib node modules as proposed, but just use the existing .cordova/config.json file to specify the cordova lib location. By default, cordova-cli uses the global npm install of cordova-lib, but that could be overwritten just like platform versions. This would also support both a global lib, upgrade all at once as well as a local lib, upgrade on demand workflow.
Re: When to do Official Apache Releases
+1 to still do these for each cadence release. I'm in a somewhat unique situation where Cordova gets bundled as a downstream distribution into a vendor product. The vendor product uses the Cordova native platforms and core plugins that get embedded in the product, the product doesn't fetch any code from git or npm. And the product itself doesn't get installed in an npm-like way. There isn't dynamic updates or dependency fetching. As we bundle those downstream distributions, I'm very used to using the official apache release tarballs. I'm fine with it being just the native platforms and docs. We don't embed the Cordova docs in the product, we just link out to cordova.apache.org/docs. And it would feel weird for an Apache project to not publish source releases. I nobody else wants to invest the time to publish an official apache release to dist.apache.org, then I can own that. -- Marcel On Sep 3, 2013, at 12:36 PM, 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: config.xml as a build artifact for less suffering and easier upgrades
On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams to...@devgeeks.orgwrote: I have been following this thread with a combination of interest and trepidation. Interest: Anything that works towards ./platforms being a build artefact I am all for. In our app, ./platforms is already a build artefact. We used hooks to achieve this (updating config files, copying icon / splash assets, etc). Just a quick question… I know that ./platforms/../config.xml (even after a `cordova build …`) still has the old defaults for name, author, id etc… but it doesn't seem to make any difference. We don't modify ./platforms/../config.xml as it seemed like the modifications to ./www/config.xml (and our custom hook modifications to say ./platforms/android/AndroidManifest.xml) were sufficient. What am I missing wrt there being differences between these files? Trepidation: Users are just starting to get a handle on how the CLI works (though there are still some ongoing issues that I see fairly regularly, like thinking they still need to use Plugman directly even with CLI created projects). Just worried more workflow changes yet again are going to turn people off the CLI entirely. I may be a bit twice shy, so if it's not going to impact users much (except for making things much better) feel free to set me straight. hehe. - tommy Some clarifications: - Change doesn't change workflow at all - Change will allow user's edits to their root config.xml actually work in all cases Win! On 10/09/2013, at 2:57 AM, Michal Mocny mmo...@chromium.org wrote: Aside from moving some files around and changing the order of operations a bit, the biggest change will be adding support for platform and config-file to app.xml. By the way, thats still called config.xml, do we want to rename it to app.xml for 3.1? On Mon, Sep 9, 2013 at 12:47 PM, Braden Shepherdson bra...@chromium.org wrote: I should certainly be able to. I'm digging into a major refactoring of Plugman right now, though, so I'll probably want to finish that. If it's taking too long, though, then I'll switch gears and get this in before we cut 3.1. Braden On Mon, Sep 9, 2013 at 11:48 AM, Michal Mocny mmo...@chromium.org wrote: Braden, are you going to be able to take this on this week? I think it would make the upgrade from 3.0 much easier. -Michal On Mon, Sep 9, 2013 at 9:48 AM, Michal Mocny mmo...@chromium.org wrote: If you would use a different helloworld app template (which is now possible to specify in both CLI and old workflow), then the pre-generatred platform config.xml template would likely be the wrong one, and thus this bundling for self documentation would be a disservice. I don't see very much value in documentation for bundling the config.xml inside the platform template (when do we suspect users look at that file, as apposed to whats actually generated inside their project?). Users can read what is generated after adding a platform for their specific app using their chosen flow. I think that since bin/create can mush defaults.xml with app.xml for both flows, it should. On Mon, Sep 9, 2013 at 9:21 AM, Ian Clelland iclell...@chromium.org wrote: On Mon, Sep 9, 2013 at 8:45 AM, Braden Shepherdson bra...@chromium.org wrote: The defaults.xml is only part of the CLI workflow, yes. It has no relevance if you're not using CLI. BUT there is a complete config.xml in the bin/create template, and it can of course have the same values as you would get from an unchanged CLI project (defaults.xml + app.xml). The configuration values you get from the templates should be the same in both cases, I agree completely. Yes, I think it's definitely achievable to have the complete template config.xml be exactly what you would get (modulo whitespace / comments / etc) from installing the same sample app on the same platform with CLI. If we can maintain that standard, then the various files become almost self-documenting; its easy to look at the final config.xml file in the template to see how the pieces should fit together, and work out where each of the tags originally came from. It might be worth trying to generate the template config.xml *using* cli, just to maintain the correspondence between them. Ian Braden On Sun, Sep 8, 2013 at 5:28 AM, James Jong wjamesj...@gmail.com wrote: Andrew - what I was thinking was pretty much what Michal wrote below. Perhaps it was my interpretation of the original note but I thought defaults was to be applied only in the CLI workflow. -James Jong On Sep 7, 2013, at 1:05 PM, Michal Mocny mmo...@chromium.org wrote: With this proposal as it stands, I think that is already true (at least for the initial contents, obviously user can make edits later). Ie, defaults.xml + app.xml = initial config.xml for both
Re: config.xml as a build artifact for less suffering and easier upgrades
Then colour me excited! +1 On 10/09/2013, at 11:27 PM, Andrew Grieve agri...@chromium.org wrote: On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams to...@devgeeks.orgwrote: I have been following this thread with a combination of interest and trepidation. Interest: Anything that works towards ./platforms being a build artefact I am all for. In our app, ./platforms is already a build artefact. We used hooks to achieve this (updating config files, copying icon / splash assets, etc). Just a quick question… I know that ./platforms/../config.xml (even after a `cordova build …`) still has the old defaults for name, author, id etc… but it doesn't seem to make any difference. We don't modify ./platforms/../config.xml as it seemed like the modifications to ./www/config.xml (and our custom hook modifications to say ./platforms/android/AndroidManifest.xml) were sufficient. What am I missing wrt there being differences between these files? Trepidation: Users are just starting to get a handle on how the CLI works (though there are still some ongoing issues that I see fairly regularly, like thinking they still need to use Plugman directly even with CLI created projects). Just worried more workflow changes yet again are going to turn people off the CLI entirely. I may be a bit twice shy, so if it's not going to impact users much (except for making things much better) feel free to set me straight. hehe. - tommy Some clarifications: - Change doesn't change workflow at all - Change will allow user's edits to their root config.xml actually work in all cases Win! On 10/09/2013, at 2:57 AM, Michal Mocny mmo...@chromium.org wrote: Aside from moving some files around and changing the order of operations a bit, the biggest change will be adding support for platform and config-file to app.xml. By the way, thats still called config.xml, do we want to rename it to app.xml for 3.1? On Mon, Sep 9, 2013 at 12:47 PM, Braden Shepherdson bra...@chromium.org wrote: I should certainly be able to. I'm digging into a major refactoring of Plugman right now, though, so I'll probably want to finish that. If it's taking too long, though, then I'll switch gears and get this in before we cut 3.1. Braden On Mon, Sep 9, 2013 at 11:48 AM, Michal Mocny mmo...@chromium.org wrote: Braden, are you going to be able to take this on this week? I think it would make the upgrade from 3.0 much easier. -Michal On Mon, Sep 9, 2013 at 9:48 AM, Michal Mocny mmo...@chromium.org wrote: If you would use a different helloworld app template (which is now possible to specify in both CLI and old workflow), then the pre-generatred platform config.xml template would likely be the wrong one, and thus this bundling for self documentation would be a disservice. I don't see very much value in documentation for bundling the config.xml inside the platform template (when do we suspect users look at that file, as apposed to whats actually generated inside their project?). Users can read what is generated after adding a platform for their specific app using their chosen flow. I think that since bin/create can mush defaults.xml with app.xml for both flows, it should. On Mon, Sep 9, 2013 at 9:21 AM, Ian Clelland iclell...@chromium.org wrote: On Mon, Sep 9, 2013 at 8:45 AM, Braden Shepherdson bra...@chromium.org wrote: The defaults.xml is only part of the CLI workflow, yes. It has no relevance if you're not using CLI. BUT there is a complete config.xml in the bin/create template, and it can of course have the same values as you would get from an unchanged CLI project (defaults.xml + app.xml). The configuration values you get from the templates should be the same in both cases, I agree completely. Yes, I think it's definitely achievable to have the complete template config.xml be exactly what you would get (modulo whitespace / comments / etc) from installing the same sample app on the same platform with CLI. If we can maintain that standard, then the various files become almost self-documenting; its easy to look at the final config.xml file in the template to see how the pieces should fit together, and work out where each of the tags originally came from. It might be worth trying to generate the template config.xml *using* cli, just to maintain the correspondence between them. Ian Braden On Sun, Sep 8, 2013 at 5:28 AM, James Jong wjamesj...@gmail.com wrote: Andrew - what I was thinking was pretty much what Michal wrote below. Perhaps it was my interpretation of the original note but I thought defaults was to be applied only in the CLI workflow. -James Jong On Sep 7, 2013, at 1:05 PM, Michal Mocny mmo...@chromium.org wrote: With this proposal as it stands, I think that is already true (at least for the initial contents, obviously user can make edits later). Ie,
Re: cordova cli global vs. local install
How about the globally installed cordova has two things that it knows how to do: 1 - proxy to your local cordova within node_modules (ala grunt-cli) 2 - cordova create would execute: mkdir helloworld cd helloworld npm init npm install --save-dev cordova ./node_modules/cordova create I think the transition from grunt - grunt-cli was pretty rocky for many people. One thing I think we could do better: have cordova remain the globally installed thing. I see two options for this: 1: Make a new npm ID for what is now cordova e.g. cordova-local. 2: (as Michal suggested) Make the existing cordova do both things by detecting if it's the globally run one vs the localling installed one. On Tue, Sep 10, 2013 at 5:55 AM, Jesse purplecabb...@gmail.com wrote: cd 3.0 npm link . cd .. cordova -v cd 3.1 npm link . cd .. cordova -v Very gruntable @purplecabbage risingj.com On Mon, Sep 9, 2013 at 9:27 PM, Tommy-Carlos Williams to...@devgeeks.org wrote: Or, we could just drop it... and just write a blog post on how to use a local cordova vs the global one in projects you want to have a specific version (i.e.: some script code example wrapper for a cordova command in ./node_modules/.bin/cordova). 0.o - tommy On 10/09/2013, at 1:42 PM, Michal Mocny mmo...@chromium.org wrote: An alternative to leveraging npm locally may be to split cli/lib node modules as proposed, but just use the existing .cordova/config.json file to specify the cordova lib location. By default, cordova-cli uses the global npm install of cordova-lib, but that could be overwritten just like platform versions. This would also support both a global lib, upgrade all at once as well as a local lib, upgrade on demand workflow.
RE: When to do Official Apache Releases
+1 to Marcel's thoughts. His situation is definitely not unique. ;) At minimum I think it would be useful to try and solicit feedback on this from a wider audience than the dev list. I imagine there are more than just the watchers on this DL that might be bundling official packages in downstream distributions. -- Ken Wallis Senior Product Manager – WebWorks BlackBerry 650-620-2404 From: Marcel Kinard [cmarc...@gmail.com] Sent: Tuesday, September 10, 2013 9:20 AM To: dev@cordova.apache.org Subject: Re: When to do Official Apache Releases +1 to still do these for each cadence release. I'm in a somewhat unique situation where Cordova gets bundled as a downstream distribution into a vendor product. The vendor product uses the Cordova native platforms and core plugins that get embedded in the product, the product doesn't fetch any code from git or npm. And the product itself doesn't get installed in an npm-like way. There isn't dynamic updates or dependency fetching. As we bundle those downstream distributions, I'm very used to using the official apache release tarballs. I'm fine with it being just the native platforms and docs. We don't embed the Cordova docs in the product, we just link out to cordova.apache.org/docs. And it would feel weird for an Apache project to not publish source releases. I nobody else wants to invest the time to publish an official apache release to dist.apache.org, then I can own that. -- Marcel On Sep 3, 2013, at 12:36 PM, 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 - 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: cordova cli global vs. local install
Wow! I went to bed and came back too much awesomeness (that's what happens when you are in the east coast :-) ) Thank you for taking the time to provide feedback and brainstorm around this topic. I agree with Michal, I think cordova-cli doesn't fit the use case perfectly because of bootstrap, cordova creates the empty directory and populates workspace where grunt already assumes directoryfile created I agree with Tommy to many commands to get started. and thanks for the tip of using npm link that could be use in the blog also I will continue brainstorm maybe there is a solution outside cordova, maybe some type of bootstrapping with template/scaffolding or cordova init But from the discussion I think there are some good outcomes that I like: *+1 Write a blog post about using cordova locally* The scenario (having one build server that runs cordova builds for different teams/apps, not all teams might want to share same cordova cli and its dependencies) Global requirements: Only node and npm install globally Installing with npm locally Running the local version (./node_modules/.bin/cordova or ./node_modules/cordova) Using npm link or modifying $PATH Checking into source control local node_modules/ including cordova cli and its dependencies (http://www.futurealoof.com/posts/nodemodules-in-git.html) Only checkin node_modules for applications you deploy, not reusable packages you maintain. etc... *+1 Version detection for cli tool* cordova and plugman to inform the user that a new version of the tool is available [Bower] (http://bower.io) does something similar: exp5:$ ./node_modules/.bin/bower install jquery - Update available: 1.2.6 (current: 1.2.5) Run npm update -g bower to update - [image: Inline image 1] *+1 I'm adding this one version reporting for platforms and plugins* What about reporting the versions of the platforms and the plugins? Today I only get a list of them but it doesn't let me know what version are installed or check if a new version is available for plugin or platform. Reporting what's install should be a good start myHybridAppFolder:(master)$ cordova platforms Installed platforms: android, ios Available platforms: blackberry10 myHybridAppFolder:(master)$ cordova plugins [ 'org.apache.cordova.core.device', 'org.apache.cordova.core.device-orientation', 'org.apache.cordova.core.dialogs', 'org.apache.cordova.core.file', 'org.apache.cordova.core.geolocation', 'org.apache.cordova.core.globalization', 'org.apache.cordova.core.inappbrowser', 'org.apache.cordova.core.media-capture', 'org.apache.cordova.core.network-information', 'org.apache.cordova.core.vibration' ] myHybridAppFolder:(master)$ On Tue, Sep 10, 2013 at 5:55 AM, Jesse purplecabb...@gmail.com wrote: cd 3.0 npm link . cd .. cordova -v cd 3.1 npm link . cd .. cordova -v Very gruntable @purplecabbage risingj.com On Mon, Sep 9, 2013 at 9:27 PM, Tommy-Carlos Williams to...@devgeeks.org wrote: Or, we could just drop it... and just write a blog post on how to use a local cordova vs the global one in projects you want to have a specific version (i.e.: some script code example wrapper for a cordova command in ./node_modules/.bin/cordova). 0.o - tommy On 10/09/2013, at 1:42 PM, Michal Mocny mmo...@chromium.org wrote: An alternative to leveraging npm locally may be to split cli/lib node modules as proposed, but just use the existing .cordova/config.json file to specify the cordova lib location. By default, cordova-cli uses the global npm install of cordova-lib, but that could be overwritten just like platform versions. This would also support both a global lib, upgrade all at once as well as a local lib, upgrade on demand workflow. -- Carlos Santana csantan...@gmail.com
Re: Serve vs. opening an HTML file in the browser
Do you get the prompt's for the calls to native? If you do press cancel which will should allow things to boot up. If not try opening your browser to *http://localhost:4400/ ?enableRipple=cordova-3.0.0 http://emulate.phonegap.com/#* On Tue, Sep 10, 2013 at 10:04 AM, Ray Camden rayca...@adobe.com wrote: That's the thing - I can't get Ripple to load. I get the console.log infinite recursion thing I've gotten with PG for a while now. I literally can't get to a point where any HTML shows and the extension can take over. On 9/9/13 5:23 PM, Gord Tanner gtan...@gmail.com wrote: Hey, got pulled off on some other stuff: Lets make sure you are not running an old copy of ripple: cordova create Baz cordova platform add android cordova prepare cd incubator-ripple jake ./bin/ripple emulate --path ../Baz/platforms/android/assets/www/ Ensure that you have cordova 3.0.0 selected as the platform.
Re: Serve vs. opening an HTML file in the browser
That's the thing - I can't get Ripple to load. I get the console.log infinite recursion thing I've gotten with PG for a while now. I literally can't get to a point where any HTML shows and the extension can take over. On 9/9/13 5:23 PM, Gord Tanner gtan...@gmail.com wrote: Hey, got pulled off on some other stuff: Lets make sure you are not running an old copy of ripple: cordova create Baz cordova platform add android cordova prepare cd incubator-ripple jake ./bin/ripple emulate --path ../Baz/platforms/android/assets/www/ Ensure that you have cordova 3.0.0 selected as the platform.
Re: Serve vs. opening an HTML file in the browser
I can confirm it works. :) Any way to bypass those alerts? (To be clear, it is easy enough for me to do, but I worry about the folks new to Ripple.) On 9/10/13 9:17 AM, Gord Tanner gtan...@gmail.com wrote: Do you get the prompt's for the calls to native? If you do press cancel which will should allow things to boot up. If not try opening your browser to *http://localhost:4400/ ?enableRipple=cordova-3.0.0 http://emulate.phonegap.com/#* On Tue, Sep 10, 2013 at 10:04 AM, Ray Camden rayca...@adobe.com wrote: That's the thing - I can't get Ripple to load. I get the console.log infinite recursion thing I've gotten with PG for a while now. I literally can't get to a point where any HTML shows and the extension can take over. On 9/9/13 5:23 PM, Gord Tanner gtan...@gmail.com wrote:
Cordova Translation Wiki Page Added
FYI, I have added a wiki page with instructions for someone who would want to run the automated translation process we have to push from git to crowdin and back to git again. Take a look and if anyone has any questions or suggestions for improvements to the wiki shoot them my way! https://wiki.apache.org/cordova/CordovaTranslations Lisa Seacat DeLuca ldel...@apache.org
Re: Serve vs. opening an HTML file in the browser
That is something I am working on in my branch ;) On Tue, Sep 10, 2013 at 10:54 AM, Ray Camden rayca...@adobe.com wrote: I can confirm it works. :) Any way to bypass those alerts? (To be clear, it is easy enough for me to do, but I worry about the folks new to Ripple.) On 9/10/13 9:17 AM, Gord Tanner gtan...@gmail.com wrote: Do you get the prompt's for the calls to native? If you do press cancel which will should allow things to boot up. If not try opening your browser to *http://localhost:4400/ ?enableRipple=cordova-3.0.0 http://emulate.phonegap.com/#* On Tue, Sep 10, 2013 at 10:04 AM, Ray Camden rayca...@adobe.com wrote: That's the thing - I can't get Ripple to load. I get the console.log infinite recursion thing I've gotten with PG for a while now. I literally can't get to a point where any HTML shows and the extension can take over. On 9/9/13 5:23 PM, Gord Tanner gtan...@gmail.com wrote:
Re: Cordova Translation Wiki Page Added
Nice write-up! Makes it quite clear as to how it all works :) On Tue, Sep 10, 2013 at 10:54 AM, Lisa Seacat DeLuca ldel...@us.ibm.comwrote: FYI, I have added a wiki page with instructions for someone who would want to run the automated translation process we have to push from git to crowdin and back to git again. Take a look and if anyone has any questions or suggestions for improvements to the wiki shoot them my way! https://wiki.apache.org/cordova/CordovaTranslations Lisa Seacat DeLuca ldel...@apache.org
Re: Releases in a 3.0 World
I think we should get the manual steps ironed out on the https://wiki.apache.org/cordova/StepsForPluginRelease site before we try to automate. I just tried what you said and got: ../cordova-plugman/main.js publish . forbidden user: agrieve not authorized to modify org.apache.cordova.core.file Changed: dist-tags.latest 0.2.1 - 0.1.0 Changed: versions.0.1.0.dist.tarball http://registry.cordova.io/org.apache.cordova.core.file/-/org.apache.cordova.core.file-0.1.0.tgz; - http://cordova.iriscouch.com/registry/_design/scratch/_rewrite/org.apache.cordova.core.file/-/org.apache.cordova.core.file-0.1.0.tgz Added: versions.0.1.0.directories Deleted: versions.0.2.1 Changed: time.modified 2013-09-09T21:45:49.845Z - 2013-09-10T17:48:52.345Z: org.apache.cordova.core.file/-rev/5-20a7ea85f95935cfcd969cc1d71230fc 1. We'll need a strategy for allowing all cordova devs to have perms to update the registry 2. It looks like even though it failed, it continued to edit the registry? On Mon, Sep 9, 2013 at 6:57 PM, Anis KADRI anis.ka...@gmail.com wrote: Reviving this thread for 3.1 One thing that is not part of [1] is publishing all plugins and updating versions to our registry. Could coho automate this process as well ? Basically we need to run plugman publish cordova-plugin-* after updating each plugin version. [1] http://wiki.apache.org/cordova/CuttingReleases On Thu, Sep 5, 2013 at 9:21 AM, Michal Mocny mmo...@chromium.org wrote: On Wed, Sep 4, 2013 at 9:17 PM, Andrew Grieve agri...@chromium.org wrote: On Wed, Sep 4, 2013 at 5:42 PM, Michal Mocny mmo...@chromium.org wrote: On Wed, Sep 4, 2013 at 5:39 PM, Michal Mocny mmo...@chromium.org wrote: On Wed, Sep 4, 2013 at 3:18 PM, Andrew Grieve agri...@chromium.org wrote: On Wed, Sep 4, 2013 at 3:15 PM, Andrew Grieve agri...@chromium.org wrote: On Wed, Sep 4, 2013 at 2:51 PM, Andrew Grieve agri...@chromium.org wrote: Responses inline. For all of them, I'll update the wiki to make things clear. 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? I'd say skip. 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? cordova-js, mobile-spec, cordova-docs, cordova-cli: Update their versions to the current CadVer plugman: Probably should be removed from this list. platform-repos: semver bump if there were any changes since prev release. == 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? Yes (will update wording) 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. Hrm, how about instead of merging dev-master, we merge CHANGELOG.md commit - master. Actually, this will work fine as-is so long as you don't git pull in the middle of things. going to leave as-is. You'll need to pull again in order to push if a commit snuck in, no? The steps right now seem to be: pull dev, Update Changelog and VERSION, push to dev. Which may perhaps be automated into such a small window that it doesn't matter, but if it includes reviewing each change and testing, then it may mean opportunity for new changes to sneak into master. For each plugin that had unreleased commits .. increment the micro -- why? So that the version on dev is greater than the version on master. I still don't understand. If the plugin had no unreleased commits, then master version didn't increment, and dev version should remain master version without a bump, no? Perhaps its supposed to say, for each plugin that *had* a release? Sounds right to me. had unreleased commits == had a release, no? Okay thats my confusion. A plugin may have commits which we decide are not important enough to warrant releasing (you clarified that earlier). So had unreleased commits to me meant all plugins whose commits on dev are not being released to master at this moment. May want to clarify the
Cordova Upgrades
Our upgrade process from 2.9 - 3.0 was to recreate a project and copy your files over. It would be sad if these were our instructions for 3.0 - 3.1. What I'd like to see: $ cd MyProject $ cordova --version 3.0.9 $ npm update -g cordova $ cordova --version 3.1.0-1.0.0 $ cordova platform ls Installed platforms: android 3.0.0 ios 3.0.0 Available platforms: android 3.1.0 ios 3.1.0 blackberry10 3.1.0 $ cordova platform add android Platform android already exists. Use `update` to update it. $ cordova platform update android Updated android from 3.0.0 to 3.1.0 $ cordova platform ls Installed platforms: android 3.1.0 ios 3.0.0 Available platforms: ios 3.1.0 blackberry10 3.1.0 How does `cordova update` work? - It uses platforms/*/cordova/version script to discover current version - It fetches the new version into $HOME/.cordova/libs - It runs new_version/bin/update path/to/platforms/$PLATFORM for the specified platform The platform script is responsible for: #1 - doing all easily automated steps (update Cordova.jar, update scripts within cordova/) #2 - Printing out a message saying what manual steps should be taken to complete the upgrade (e.g. Please add this snippet to your ApplicationDelegate) Sound good? Any other ideas?
Re: config.xml as a build artifact for less suffering and easier upgrades
Issue Created - https://issues.apache.org/jira/browse/CB-4774 On 13-09-10 9:30 AM, Tommy-Carlos Williams to...@devgeeks.org wrote: Then colour me excited! +1 On 10/09/2013, at 11:27 PM, Andrew Grieve agri...@chromium.org wrote: On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams to...@devgeeks.orgwrote: I have been following this thread with a combination of interest and trepidation. Interest: Anything that works towards ./platforms being a build artefact I am all for. In our app, ./platforms is already a build artefact. We used hooks to achieve this (updating config files, copying icon / splash assets, etc). Just a quick questionŠ I know that ./platforms/../config.xml (even after a `cordova build Š`) still has the old defaults for name, author, id etcŠ but it doesn't seem to make any difference. We don't modify ./platforms/../config.xml as it seemed like the modifications to ./www/config.xml (and our custom hook modifications to say ./platforms/android/AndroidManifest.xml) were sufficient. What am I missing wrt there being differences between these files? Trepidation: Users are just starting to get a handle on how the CLI works (though there are still some ongoing issues that I see fairly regularly, like thinking they still need to use Plugman directly even with CLI created projects). Just worried more workflow changes yet again are going to turn people off the CLI entirely. I may be a bit twice shy, so if it's not going to impact users much (except for making things much better) feel free to set me straight. hehe. - tommy Some clarifications: - Change doesn't change workflow at all - Change will allow user's edits to their root config.xml actually work in all cases Win! On 10/09/2013, at 2:57 AM, Michal Mocny mmo...@chromium.org wrote: Aside from moving some files around and changing the order of operations a bit, the biggest change will be adding support for platform and config-file to app.xml. By the way, thats still called config.xml, do we want to rename it to app.xml for 3.1? On Mon, Sep 9, 2013 at 12:47 PM, Braden Shepherdson bra...@chromium.org wrote: I should certainly be able to. I'm digging into a major refactoring of Plugman right now, though, so I'll probably want to finish that. If it's taking too long, though, then I'll switch gears and get this in before we cut 3.1. Braden On Mon, Sep 9, 2013 at 11:48 AM, Michal Mocny mmo...@chromium.org wrote: Braden, are you going to be able to take this on this week? I think it would make the upgrade from 3.0 much easier. -Michal On Mon, Sep 9, 2013 at 9:48 AM, Michal Mocny mmo...@chromium.org wrote: If you would use a different helloworld app template (which is now possible to specify in both CLI and old workflow), then the pre-generatred platform config.xml template would likely be the wrong one, and thus this bundling for self documentation would be a disservice. I don't see very much value in documentation for bundling the config.xml inside the platform template (when do we suspect users look at that file, as apposed to whats actually generated inside their project?). Users can read what is generated after adding a platform for their specific app using their chosen flow. I think that since bin/create can mush defaults.xml with app.xml for both flows, it should. On Mon, Sep 9, 2013 at 9:21 AM, Ian Clelland iclell...@chromium.org wrote: On Mon, Sep 9, 2013 at 8:45 AM, Braden Shepherdson bra...@chromium.org wrote: The defaults.xml is only part of the CLI workflow, yes. It has no relevance if you're not using CLI. BUT there is a complete config.xml in the bin/create template, and it can of course have the same values as you would get from an unchanged CLI project (defaults.xml + app.xml). The configuration values you get from the templates should be the same in both cases, I agree completely. Yes, I think it's definitely achievable to have the complete template config.xml be exactly what you would get (modulo whitespace / comments / etc) from installing the same sample app on the same platform with CLI. If we can maintain that standard, then the various files become almost self-documenting; its easy to look at the final config.xml file in the template to see how the pieces should fit together, and work out where each of the tags originally came from. It might be worth trying to generate the template config.xml *using* cli, just to maintain the correspondence between them. Ian Braden On Sun, Sep 8, 2013 at 5:28 AM, James Jong wjamesj...@gmail.com wrote: Andrew - what I was thinking was pretty much what Michal wrote below. Perhaps it was my interpretation of the original note but I thought defaults was to be applied only in the CLI workflow. -James Jong On Sep 7, 2013, at 1:05 PM, Michal Mocny mmo...@chromium.org wrote: With this proposal as it stands, I think that is already true (at
Re: 3.1 Release
Sure! New plan: Monday 16th - Create release branches tag RC of all repos Tuesday 17th - Draft Release Blog Post (digest of changelogs) Monday 20th - Tag 3.1.0 for all repos Tuesday 21st - Push 3.1.0-1.0.0 of CLI to npm Post blog post While we're at it, anyone want to volunteer to be Release Master? ( https://wiki.apache.org/cordova/ReleaseMaster) Any of our Component Leads want to not be? Android: Joe BlackBerry: Lorin CLI: Braden JS: Andrew Docs: Michael B iOS: Shaz Windows: Jesse OSX: Shaz On Tue, Sep 10, 2013 at 2:33 PM, Joe Bowser bows...@gmail.com wrote: Can we move this so it happens on Mondays instead of Fridays. Releasing on a Friday is never a good idea, especially since we're going to be MIA for those two Fridays with internal stuff at the Vancouver Adobe office). On Mon, Sep 9, 2013 at 8:10 AM, James Jong wjamesj...@gmail.com wrote: Andrew, thanks for kicking it off. Also should note inclusion of iOS 7 support. -James Jong On Sep 9, 2013, at 10:42 AM, Andrew Grieve agri...@chromium.org wrote: I think it's time to get the ball rolling on this. It'll be the first release post-3.0, so will likely have a few bumps to work through. How about: Friday 13th - Create release branches tag RC of all repos Monday 16th - Draft Release Blog Post (digest of changelogs) Thurs 19th - Tag 3.1.0 for all repos Fri 20th - Push 3.1.0-1.0.0 of CLI to npm Post blog post The main feature of this release will be plugman-registry I think. That said, since CLI / Plugman aren't tied to cadence releases, I think it's just cordova-docs that is relevant.
Re: When to do Official Apache Releases
Sounds like we should still do them :) On Tue, Sep 10, 2013 at 9:41 AM, Ken Wallis kwal...@blackberry.com wrote: +1 to Marcel's thoughts. His situation is definitely not unique. ;) At minimum I think it would be useful to try and solicit feedback on this from a wider audience than the dev list. I imagine there are more than just the watchers on this DL that might be bundling official packages in downstream distributions. -- Ken Wallis Senior Product Manager – WebWorks BlackBerry 650-620-2404 From: Marcel Kinard [cmarc...@gmail.com] Sent: Tuesday, September 10, 2013 9:20 AM To: dev@cordova.apache.org Subject: Re: When to do Official Apache Releases +1 to still do these for each cadence release. I'm in a somewhat unique situation where Cordova gets bundled as a downstream distribution into a vendor product. The vendor product uses the Cordova native platforms and core plugins that get embedded in the product, the product doesn't fetch any code from git or npm. And the product itself doesn't get installed in an npm-like way. There isn't dynamic updates or dependency fetching. As we bundle those downstream distributions, I'm very used to using the official apache release tarballs. I'm fine with it being just the native platforms and docs. We don't embed the Cordova docs in the product, we just link out to cordova.apache.org/docs. And it would feel weird for an Apache project to not publish source releases. I nobody else wants to invest the time to publish an official apache release to dist.apache.org, then I can own that. -- Marcel On Sep 3, 2013, at 12:36 PM, 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 - 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.
iOS 7 went GM
download the GM Xcode from the iOS Dev Center. I suppose we can finalize iOS 7 support/testing.
Re: Cordova Upgrades
YES! I've been wanting something like this since 2.4 :-) On Tue, Sep 10, 2013 at 12:37 PM, Andrew Grieve agri...@chromium.org wrote: Made tasks for this on JIRA: https://issues.apache.org/jira/browse/CB-4776 Feel free to continue discussing here. On Tue, Sep 10, 2013 at 1:48 PM, Michael Brooks mich...@michaelbrooks.cawrote: Effectively, this could also be used to downgrade a project because it's updating the project to match the globally installed Cordova version. Looks good though! It's important to keep the upgrade responsibility within the platform scripts. Michael On Tue, Sep 10, 2013 at 8:30 AM, Andrew Grieve agri...@chromium.org wrote: Our upgrade process from 2.9 - 3.0 was to recreate a project and copy your files over. It would be sad if these were our instructions for 3.0 - 3.1. What I'd like to see: $ cd MyProject $ cordova --version 3.0.9 $ npm update -g cordova $ cordova --version 3.1.0-1.0.0 $ cordova platform ls Installed platforms: android 3.0.0 ios 3.0.0 Available platforms: android 3.1.0 ios 3.1.0 blackberry10 3.1.0 $ cordova platform add android Platform android already exists. Use `update` to update it. $ cordova platform update android Updated android from 3.0.0 to 3.1.0 $ cordova platform ls Installed platforms: android 3.1.0 ios 3.0.0 Available platforms: ios 3.1.0 blackberry10 3.1.0 How does `cordova update` work? - It uses platforms/*/cordova/version script to discover current version - It fetches the new version into $HOME/.cordova/libs - It runs new_version/bin/update path/to/platforms/$PLATFORM for the specified platform The platform script is responsible for: #1 - doing all easily automated steps (update Cordova.jar, update scripts within cordova/) #2 - Printing out a message saying what manual steps should be taken to complete the upgrade (e.g. Please add this snippet to your ApplicationDelegate) Sound good? Any other ideas?
Re: iOS 7 went GM
Sounds good! No reason not to insist on this. It's a free download and doesn't change the system requirements (at least they don't mention that it does) On Tue, Sep 10, 2013 at 4:38 PM, Shazron shaz...@gmail.com wrote: Also, Apple just sent out the email Submit your iOS 7 apps today using Xcode 5 GM. So I say once iOS 7 goes GA (Sept 20?) we say Cordova only supports Xcode 5 going forward (since that will be the requirement for submitting to the App Store) On Tue, Sep 10, 2013 at 1:21 PM, Shazron shaz...@gmail.com wrote: download the GM Xcode from the iOS Dev Center. I suppose we can finalize iOS 7 support/testing.
Re: Cordova Upgrades
Made tasks for this on JIRA: https://issues.apache.org/jira/browse/CB-4776 Feel free to continue discussing here. On Tue, Sep 10, 2013 at 1:48 PM, Michael Brooks mich...@michaelbrooks.cawrote: Effectively, this could also be used to downgrade a project because it's updating the project to match the globally installed Cordova version. Looks good though! It's important to keep the upgrade responsibility within the platform scripts. Michael On Tue, Sep 10, 2013 at 8:30 AM, Andrew Grieve agri...@chromium.org wrote: Our upgrade process from 2.9 - 3.0 was to recreate a project and copy your files over. It would be sad if these were our instructions for 3.0 - 3.1. What I'd like to see: $ cd MyProject $ cordova --version 3.0.9 $ npm update -g cordova $ cordova --version 3.1.0-1.0.0 $ cordova platform ls Installed platforms: android 3.0.0 ios 3.0.0 Available platforms: android 3.1.0 ios 3.1.0 blackberry10 3.1.0 $ cordova platform add android Platform android already exists. Use `update` to update it. $ cordova platform update android Updated android from 3.0.0 to 3.1.0 $ cordova platform ls Installed platforms: android 3.1.0 ios 3.0.0 Available platforms: ios 3.1.0 blackberry10 3.1.0 How does `cordova update` work? - It uses platforms/*/cordova/version script to discover current version - It fetches the new version into $HOME/.cordova/libs - It runs new_version/bin/update path/to/platforms/$PLATFORM for the specified platform The platform script is responsible for: #1 - doing all easily automated steps (update Cordova.jar, update scripts within cordova/) #2 - Printing out a message saying what manual steps should be taken to complete the upgrade (e.g. Please add this snippet to your ApplicationDelegate) Sound good? Any other ideas?
Our Dev Flow Sucks
Hey So, I'm trying to catch up on all the changes that have been done, and I'm finding that EVERYTHING IS BROKEN! While a bunch of changes were done on master, they break what's on master in the plugins because we do plugin dev in the dev branch. Also, I don't see any documented way of switching to all the branches with coho that's documented, so I have no idea how we're supposed to do dev on this thing anymore. Can we please do the same thing with plugins that we do with the platforms? Plugins don't have to have the same version numbers as the platforms, but it would be good if master on the platforms matched up to what we would expect to see on the plugins. This dev branch crap is slowing things down and making things much harder. Joe
Re: Serve vs. opening an HTML file in the browser
Ok - so anything else I can test - or just chill for now? On 9/10/13 10:00 AM, Gord Tanner gtan...@gmail.com wrote: That is something I am working on in my branch ;) On Tue, Sep 10, 2013 at 10:54 AM, Ray Camden rayca...@adobe.com wrote: I can confirm it works. :) Any way to bypass those alerts? (To be clear, it is easy enough for me to do, but I worry about the folks new to Ripple.)
Re: iOS 7 went GM
Also, Apple just sent out the email Submit your iOS 7 apps today using Xcode 5 GM. So I say once iOS 7 goes GA (Sept 20?) we say Cordova only supports Xcode 5 going forward (since that will be the requirement for submitting to the App Store) On Tue, Sep 10, 2013 at 1:21 PM, Shazron shaz...@gmail.com wrote: download the GM Xcode from the iOS Dev Center. I suppose we can finalize iOS 7 support/testing.
Re: Cordova Upgrades
Effectively, this could also be used to downgrade a project because it's updating the project to match the globally installed Cordova version. Looks good though! It's important to keep the upgrade responsibility within the platform scripts. Michael On Tue, Sep 10, 2013 at 8:30 AM, Andrew Grieve agri...@chromium.org wrote: Our upgrade process from 2.9 - 3.0 was to recreate a project and copy your files over. It would be sad if these were our instructions for 3.0 - 3.1. What I'd like to see: $ cd MyProject $ cordova --version 3.0.9 $ npm update -g cordova $ cordova --version 3.1.0-1.0.0 $ cordova platform ls Installed platforms: android 3.0.0 ios 3.0.0 Available platforms: android 3.1.0 ios 3.1.0 blackberry10 3.1.0 $ cordova platform add android Platform android already exists. Use `update` to update it. $ cordova platform update android Updated android from 3.0.0 to 3.1.0 $ cordova platform ls Installed platforms: android 3.1.0 ios 3.0.0 Available platforms: ios 3.1.0 blackberry10 3.1.0 How does `cordova update` work? - It uses platforms/*/cordova/version script to discover current version - It fetches the new version into $HOME/.cordova/libs - It runs new_version/bin/update path/to/platforms/$PLATFORM for the specified platform The platform script is responsible for: #1 - doing all easily automated steps (update Cordova.jar, update scripts within cordova/) #2 - Printing out a message saying what manual steps should be taken to complete the upgrade (e.g. Please add this snippet to your ApplicationDelegate) Sound good? Any other ideas?
Re: iOS 7 went GM
Xcode 5 does require at least Mountain Lion (10.8) while Xcode 4.6.3 you could still use Lion (10.7) From the download page: Xcode 5 GM seed requires OS X Mountain Lion or later. On Tue, Sep 10, 2013 at 1:53 PM, Andrew Grieve agri...@chromium.org wrote: Sounds good! No reason not to insist on this. It's a free download and doesn't change the system requirements (at least they don't mention that it does) On Tue, Sep 10, 2013 at 4:38 PM, Shazron shaz...@gmail.com wrote: Also, Apple just sent out the email Submit your iOS 7 apps today using Xcode 5 GM. So I say once iOS 7 goes GA (Sept 20?) we say Cordova only supports Xcode 5 going forward (since that will be the requirement for submitting to the App Store) On Tue, Sep 10, 2013 at 1:21 PM, Shazron shaz...@gmail.com wrote: download the GM Xcode from the iOS Dev Center. I suppose we can finalize iOS 7 support/testing.
