Re: Plugin Version Control Workflow
Hi Andrey, I have worked on two small, simple Cordova applications, but we still at times had to modify platform specific code. Not much, but some (AppDelegate.m for the iOS app, and the DroidGap subclass for Android--this is a 2.9.x project for now). Here's my solutions to your issues. * if you need to modify native plugin code, you should fork the repo and manage your changes via a git project, not in your project. If you use a recent enough version of Cordova, you can even pull plugins off git branches ( see https://issues.apache.org/jira/browse/CB-4981 ) so you could have different versions of your apps for different clients pull different branches of the same plugin. * if you need to modify code under platforms, use an after_platform_add hook, and keep your customized platform files elsewhere in your project tree. This way, you aren't version controlling everything, just what you've had to change. Of course, when the Cordova platform changes underneath you (perhaps a new method is added to AppDelegate.m, and the version you have in source control overwrites that), you need to check these files carefully. But when you version control everything and you upgrade, you have to merge in your custom changes into the new Cordova code in the same careful manner, plus you are carrying around everything else under platforms. Of course, I'm a big believer in the CLI, having everyone use the entire CLI toolchain, and treating everything under platforms and plugins as derived code that you can replace at any time. If this isn't how you develop (if you prefer the 'native project dev' workflow, for example), then this may not work for you. Thanks. Dan PS Can you explain how keeping all the code in source control makes your merges as you move from Cordova version to Cordova version easier? To me, that would seem to make them more difficult. On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov kant2...@googlemail.com wrote: About plugin and platform version control. I heard a lot about that, and confused why you think that everybody would like to remove ./plugins and ./platforms folders from source control. I do agree that this is most likely the case for the simple applications and for the maybe 99% of current Cordova users, but I don't believe that this is truly important for the Cordova as the ecosystem for the cross-platform of the mobile development. Let me explain why I think that keep ./platforms and ./plugins under source control very important. I would base my reasoning on my current project needs. I currently develop 2 similar products for different clients from the same domain. I understand that in future I will have another clients from same problem domain which would like to have similar applications, just with different design. So I take the route of having 1 product line and customization of that product line for each client, depends on their needs. This is client facing application, so I would like to cover as much mobile platforms as possible with minimum amount of efforts. Currently I support only Android and iOS platforms, but envision that my clients will expand to the Windows Phone soon, and maybe I will force them to support Tizen in next year if that platform would be world-wide popular. I position my self as a) heavy Cordova user b) middle/low platform specific development. (I have to go deep in each platform, but that's not priority for me as Cordova users) I maintain 3 Git branches. 1 branch for core product and 2 branches for each client. In each branch I keep, platform specific code for the application (cordova-platform-ios/android code), Cordova plugins code + plugins developed specifically to this application. I definitely sure that I will need to add some functionality to the core platforms, either iOS or Android which will benefit the my application. I would try to push to the core Cordova as much as I can, but possible that not all contribution would be useful for the Cordova. Either way I plan for update to next version of Cordova (3.4, or 3.5 whenether). To keep my changes, which I add to current version of Cordova (3.3) and make update to 3.4 and later easier I keep all code in the source control to make all my future merges easier. Same rules apply to the plugins,maybe I add some code/fixes to plugins, or not don't matter - I have to plan for that. I would like to contribute to Cordova everything what will benefit the community to meet my selfish goals: I want to make my upgrade path as straightforward as possible, for platform code and for plugins code. Maybe I was too verbose, but that was just to explain that I plan to align my long-term goals with Cordova's long-term goals. I try to gave more explanation, so you guys could plan not only for people which create projects which are working on the specific version of Cordova, but also for the guys which want to nurture their product together with Cordova. I plainly don't see: a) how I
Re: Google Glass Support
Hi Ross. Wow, this will be really cool! You can manipulate the Android manifest and listen for intents with a plugin. See this example plugin.xml that does so: https://github.com/8zrealestate/android-referrer-plugin/blob/master/plugin.xml Some of the limits of plugins right now (unless things have radically changed since I looked at them in Cordova 3.0): * you cannot remove nodes from an xml file * you cannot change values or attributes of xml file nodes * you can't modify any other kind of file. If you need to do any of the above kind of file manipulation, you should use a hook. But I don't know a way to include a hook into a plugin. -- Dan Moore https://leanpub.com/developingwithcordovacli/
Re: CLI version to install
Hi John, I believe npm view cordova shows all the versions available in npm. Dan
Re: RELEASENOTES.md and coho
Hi folks, As a user, having all the release information in one place would be fantastic. I understand your desire to have a rapid release schedule (documented, as best as I can tell, here: http://phonegap.com/2012/04/12/rolling-releases-how-apache-cordova-becomes-phonegap-and-why/ ). But for normal app developers, having a clear understanding of what they get when upgrading (what features, bug fixes, improvements, etc have happened since the last release) is extremely helpful. Doing this will probably increase adoption of the latest versions of cordova. Another option different from having everything on one blog would be to do something like what phonegap.com/blog does--a mix of content hosted there and content excerpts pulled in from other blogs. (I don't know the exact mechanism nor how hard it would be to implement, though.) Cheers, Dan On Wednesday, December 11, 2013 11:39 AM, Andrew Grieve agri...@chromium.org wrote: Joe - would you be willing to write the blog post on Cordova's blog instead of a personal blog? Each cordova blog post does have an author with an optional link. I think having things on Cordova's blog rather than personal / downstream ones makes things more trusted discoverable. On Wed, Dec 11, 2013 at 1:27 PM, Joe Bowser bows...@gmail.com wrote: On Wed, Dec 11, 2013 at 10:23 AM, Andrew Grieve agri...@chromium.org wrote: Yep, my main concern is communicating what's changed to our users for releases. Whether this file actually exists, or when it's updated, I care less about. Joe - if you don't think a single blog post is a good way to communicating this, what's a good alternative? Should we have each platform write a blog post as a part of the release instead of release notes? Yes, because until recently that's what we did. Shaz wrote the iOS one, and either Simon or I wrote a blog post about Android. These would then be syndicated and put on the phonegap.com blog. We used to have a perfectly good solution to this problem which went away roughly around when 3.0.0 came out. This mostly went away because of time constraints and the fact that my own blog sucks ass and needs to be migrated to a real server. I think we need to go back to this. Also, this is a good way for people to get exposure and get their name out there, so there's way more reward for doing this than just writing RELEASENOTES.md which will be buried in the release and may or may not be read. On Wed, Dec 11, 2013 at 11:05 AM, Josh Soref jso...@blackberry.com wrote: Michal wrote: when doing a release, you usually have to make a mental note of what is worth testing, which usually means going through the changelog anyway, which means it isn't really adding serious time to the release process. However, this shouldn't be codified into our processes, and should be the responsibility of whoever is doing the blog post, not whoever is doing the release, and those two aren't always the same. +1 One problem is that the release blog seems to be pro forma and hurried. I've written release notes with blog entries. Doing them well is worthwhile. A few things that can help: 1. Tagging issues at filing / analysis / resolution with a release note indicator (yes, no) 2. Working on the release notes before the release process finishes - you probably already have 90% of the release fixes known a few days before d day. The last fixes can be yes/no as they're committed. 3. It's important not to have Fixed x; backed out fix for x. People reading release notes don't care about the process between the previous release and now, they want a clear indication of what has actually changed. So lets remove the requirement, and I guess the RELEASNOTES.md file from the repos? +1 - 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: library use in plugins
Hi Erik, Here is a stackoverflow question that might address some of your concerns, at least around ios frameworks: http://stackoverflow.com/questions/19803542/how-to-add-a-third-party-framework-to-a-cordova-3-0-custom-plugin/20026559#20026559 Dan
Re: Media device does not initiate
Hi Peter, This is a mailing list about the development of the Cordova framework. For questions regarding actual use of Cordova, you should post to the google group: https://groups.google.com/forum/m/#!forum/phonegap Thanks, Dan
Re: Tag 2.9.1
Hi folks, I know this is a dev list, so please let me know if I'm out of line posting (since I am a user and not a dev), but I couldn't restrain myself from chiming in on this issue. First, thanks for supporting 2.9.x for a while. As a user developing on top of Cordova, chasing Cordova versions can be tough. I really felt good about committing to 2.9, especially since 3.x was such a big (good, but big) change. As a user, I would advocate for: * having a clear end of life date for 2.9.x (3.5 or 6 months or whichever comes first). The blog is a fine place to put this, but I'd also add it to the 2.9 docs, announce it on the phonegap google group, etc. * porting as much as possible back (including iOS 7 support) * documenting what you can't or won't backport in the blog and in the 2.9.x docs, so users can make an informed choice. From this thread, seems like you aren't interested in porting new device support back to 2.9.x. That is a bummer. Is that because of the effort? When I read that 2.9.x was going to be supported for a 'long time': http://www.infil00p.org/introducing-cordova-2-8-1-on-android/ I wasn't sure what that meant, but I hoped it meant support for major new versions of devices (especially on the two marquee platforms). As far as no one moving to 3.x, I would say that when you specify the end of life of 2.9.x, that will be a clear signal it is time to move. Anyway, I'm sure I can live with whatever is decided, but please do communicate this as clearly and loudly as you can to us users. Thanks! -- Dan Moore Developing with Cordova CLI https://leanpub.com/developingwithcordovacli From: Brian LeRoux b...@brian.io To: dev@cordova.apache.org dev@cordova.apache.org Sent: Wednesday, October 16, 2013 9:02 AM Subject: Re: Tag 2.9.1 yes and yes! On Wed, Oct 16, 2013 at 9:49 AM, Marcel Kinard cmarc...@gmail.com wrote: So my intepretation of these comments is: - backport fixes to 2.9 for serious platform breakages and easy plugin changes, not new features (new device OS capability such as iOS 7 is considered a new feature) - stop backporting anything to 2.9 when 3.5 comes out If so, should this be spelled out somwhere, such as cordova.apache.org/blog? On Oct 15, 2013, at 8:24 PM, Brian LeRoux b...@brian.io wrote: 3.5 (Or six months.) But ya, what Jesse said. On Tuesday, October 15, 2013, Jesse wrote: I would not add iOS7 support. I would consider adding any plugin changes if it is not too difficult to do so. @purplecabbage risingj.com On Tue, Oct 15, 2013 at 4:56 PM, Shazron shaz...@gmail.comjavascript:; wrote: Nothing is completely broken in iOS 7, although with iOS 7 issues that is debatable. If we keep patching 2.9.x no one will move on to 3.x... (at least for iOS). There has to be an ending... On Tue, Oct 15, 2013 at 4:53 PM, Jesse purplecabb...@gmail.com javascript:; wrote: Decide what is completely broken in your platform, that is reasonable to fix, and fix it. No promises ... just fix what we can, and document that it is fixed. I think... @purplecabbage risingj.com On Tue, Oct 15, 2013 at 3:10 PM, Shazron shaz...@gmail.com javascript:; wrote: One question about this that was not answered. When does back-porting end? I'm not sure what we promised for 2.9.x support going forward... On Tue, Oct 15, 2013 at 1:16 PM, Jesse purplecabb...@gmail.com javascript:; wrote: Okay, I am actively working on back-porting plugin fixes into 2.9.1 for WP7, WP8, and Windows8 What is the status of Android, BB, iOS, ... ? @purplecabbage risingj.com On Mon, Oct 7, 2013 at 12:58 PM, Jesse MacFadyen purplecabb...@gmail.com javascript:; wrote: Yes, now that 3.1.0 is out the door, we can do this. Sent from my iPad On Oct 7, 2013, at 10:36 AM, Joe Bowser bows...@gmail.com javascript:; wrote: I think we need to just have everyone go through their work over the past month and see if they missed backports. I didn't actually have very much missed, and I just backported the File plugin in the 2.9.1 branch. Of course, with backporting, we need more people to look at what was in 3.1.0 and the plugins and check to make sure we backport everything, since this is really tricky and spans all the plugin repos. :( On Mon, Oct 7, 2013 at 10:00 AM, Marcel Kinard cmarc...@gmail.com javascript:; wrote: This thread seems to have gone quiet without a consensus. Should there be additional 2.9.x releases going forward? If so, how often? What kind of fixes should be backported? Include updated docs? On Oct 1, 2013, at 2:50 PM, Jesse purplecabb...@gmail.com javascript:; wrote: As soon as we are done with 3.1.0 it would be a good time to go back and back-fill for a 2,9,1 release. Who's with me?
Re: Tag 2.9.1
Hi folks, I know this is a dev list, so please let me know if I'm out of line posting (since I am a user and not a dev), but I couldn't restrain myself from chiming in on this issue. First, thanks for supporting 2.9.x for a while. As a user developing on top of Cordova, chasing Cordova versions can be tough. I really felt good about committing to 2.9, especially since 3.x was such a big (good, but big) change. As a user, I would advocate for: * having a clear end of life date for 2.9.x (3.5 or 6 months or whichever comes first). The blog is a fine place to put this, but I'd also add it to the 2.9 docs, announce it on the phonegap google group, etc. * porting as much as possible back (including iOS 7 support) * documenting what you can't or won't backport in the blog and in the 2.9.x docs, so users can make an informed choice. From this thread, seems like you aren't interested in porting new device support back to 2.9.x. That is a bummer. Is that because of the effort? When I read that 2.9.x was going to be supported for a 'long time': http://www.infil00p.org/introducing-cordova-2-8-1-on-android/ I wasn't sure what that meant, but I hoped it meant support for major new versions of devices (especially on the two marquee platforms). As far as no one moving to 3.x, I would say that when you specify the end of life of 2.9.x, that will be a clear signal it is time to move. Anyway, I'm sure I can live with whatever is decided, but please do communicate this as clearly and loudly as you can to us users. Thanks! -- Dan Moore Developing with Cordova CLI https://leanpub.com/developingwithcordovacli From: Brian LeRoux b...@brian.io To: dev@cordova.apache.org dev@cordova.apache.org Sent: Wednesday, October 16, 2013 9:02 AM Subject: Re: Tag 2.9.1 yes and yes! On Wed, Oct 16, 2013 at 9:49 AM, Marcel Kinard cmarc...@gmail.com wrote: So my intepretation of these comments is: - backport fixes to 2.9 for serious platform breakages and easy plugin changes, not new features (new device OS capability such as iOS 7 is considered a new feature) - stop backporting anything to 2.9 when 3.5 comes out If so, should this be spelled out somwhere, such as cordova.apache.org/blog? On Oct 15, 2013, at 8:24 PM, Brian LeRoux b...@brian.io wrote: 3.5 (Or six months.) But ya, what Jesse said. On Tuesday, October 15, 2013, Jesse wrote: I would not add iOS7 support. I would consider adding any plugin changes if it is not too difficult to do so. @purplecabbage risingj.com On Tue, Oct 15, 2013 at 4:56 PM, Shazron shaz...@gmail.comjavascript:; wrote: Nothing is completely broken in iOS 7, although with iOS 7 issues that is debatable. If we keep patching 2.9.x no one will move on to 3.x... (at least for iOS). There has to be an ending... On Tue, Oct 15, 2013 at 4:53 PM, Jesse purplecabb...@gmail.com javascript:; wrote: Decide what is completely broken in your platform, that is reasonable to fix, and fix it. No promises ... just fix what we can, and document that it is fixed. I think... @purplecabbage risingj.com On Tue, Oct 15, 2013 at 3:10 PM, Shazron shaz...@gmail.com javascript:; wrote: One question about this that was not answered. When does back-porting end? I'm not sure what we promised for 2.9.x support going forward... On Tue, Oct 15, 2013 at 1:16 PM, Jesse purplecabb...@gmail.com javascript:; wrote: Okay, I am actively working on back-porting plugin fixes into 2.9.1 for WP7, WP8, and Windows8 What is the status of Android, BB, iOS, ... ? @purplecabbage risingj.com On Mon, Oct 7, 2013 at 12:58 PM, Jesse MacFadyen purplecabb...@gmail.com javascript:; wrote: Yes, now that 3.1.0 is out the door, we can do this. Sent from my iPad On Oct 7, 2013, at 10:36 AM, Joe Bowser bows...@gmail.com javascript:; wrote: I think we need to just have everyone go through their work over the past month and see if they missed backports. I didn't actually have very much missed, and I just backported the File plugin in the 2.9.1 branch. Of course, with backporting, we need more people to look at what was in 3.1.0 and the plugins and check to make sure we backport everything, since this is really tricky and spans all the plugin repos. :( On Mon, Oct 7, 2013 at 10:00 AM, Marcel Kinard cmarc...@gmail.com javascript:; wrote: This thread seems to have gone quiet without a consensus. Should there be additional 2.9.x releases going forward? If so, how often? What kind of fixes should be backported? Include updated docs? On Oct 1, 2013, at 2:50 PM, Jesse purplecabb...@gmail.com javascript:; wrote: As soon as we are done with 3.1.0 it would be a good time to go back and back-fill for a 2,9,1 release. Who's with me?
