Re: plugins release?
Julio, I would be happy to pair with you on some plugin releases. As you already noticed, the release processes via coho need some serious work now that we are on GitHub issues instead of JIRA, so we have some additional work ahead of us. First step would be to identify which plugin to start with. (I suggest selecting just 1 and seeing that through, then continue with more if/when we are successful). @Oliver: What you wrote mainly applies to the platforms - the plugin release process should be independent from that. But we will keep that in mind of course. J Am Di., 16. Okt. 2018 um 13:34 Uhr schrieb Oliver Salzburg : > > I believe the issue with the pending releases is not that nobody is > performing the release task. There are still implementation details > being worked on if I'm not mistaken. > > The next release will supposedly introduce several major breaking > changes, which have to be prepared for thoroughly. > > On 2018-10-13 22:02, julio cesar sanchez wrote: > > Today I was checking github issues and noticed that a lot of them were > > supposedly fixed already, but people are reporting them again as we have > > not done a release since April and they are using the latest release and > > not master. > > > > So, is anybody willing to do a release? If not I can try, but last time I > > tried I wasn't able to finish it because of some problem with coho. > > > > Also, related to coho, it supposedly creates a JIRA issue, but that's not > > possible anymore, so should we manually create a release issue per plugin? > > Or patch coho to automatically create them? (if possible). > > How are you doing it since we switched to github issues? (cc Chris as I > > think you did most/all releases since then) > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: plugins release?
I believe the issue with the pending releases is not that nobody is performing the release task. There are still implementation details being worked on if I'm not mistaken. The next release will supposedly introduce several major breaking changes, which have to be prepared for thoroughly. On 2018-10-13 22:02, julio cesar sanchez wrote: Today I was checking github issues and noticed that a lot of them were supposedly fixed already, but people are reporting them again as we have not done a release since April and they are using the latest release and not master. So, is anybody willing to do a release? If not I can try, but last time I tried I wasn't able to finish it because of some problem with coho. Also, related to coho, it supposedly creates a JIRA issue, but that's not possible anymore, so should we manually create a release issue per plugin? Or patch coho to automatically create them? (if possible). How are you doing it since we switched to github issues? (cc Chris as I think you did most/all releases since then) - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Plugins release prep: Cherry-picking plugin updates
Steven, thanks so much for all your help getting the plugins released. -Original Message- From: Murat Sutunc [mailto:mura...@microsoft.com] Sent: Wednesday, May 6, 2015 1:42 PM To: dev@cordova.apache.org Subject: RE: Plugins release prep: Cherry-picking plugin updates Hey, took me a while but we're good to go with: Camera, device-motion, dialogs and vibration. Thanks! -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, May 6, 2015 12:16 PM To: dev@cordova.apache.org Subject: Re: Plugins release prep: Cherry-picking plugin updates Sounds good. Thanks Rob On Wed, May 6, 2015 at 12:04 PM, Rob Paveza rob.pav...@microsoft.com wrote: Murat is still working on the merge to master for the Camera plugin. I'll let you know when we're all squared away. -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, May 6, 2015 11:57 AM To: dev@cordova.apache.org Subject: Re: Plugins release prep: Cherry-picking plugin updates I haven't heard back. Should I move forward with those 5 plugins? file-transfer, device-motion, dialogs, vibration, and camera. I will update the process to support specific plugins release (instead of all plugins) as I work through it. On Tue, May 5, 2015 at 12:29 PM, Jesse purplecabb...@gmail.com wrote: + file-transfer so we can resolve CB-8951 @purplecabbage risingj.com On Tue, May 5, 2015 at 12:19 PM, Steven Gill stevengil...@gmail.com wrote: Hey guys, I can help you out. The process is designed for all plugins but it is pretty easy to do it for just a few. I've done it many times. If changes are on master, they shouldn't be incomplete. Any known problem with release the master branch of those plugins? We could cherry-pick, but it is just more work than probably required. Since we don't have release branches for plugins, just tags. If you guys merge changes into master, I can take over the release or at least tell you the parts to modify in the release process to make it work. -Steve On Tue, May 5, 2015 at 11:44 AM, Rob Paveza rob.pav...@microsoft.com wrote: Hi all - I started a [discuss] thread about plugin updates last week, effectively saying that we wanted to take four JIRA items which are causing problems for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943. Since Murat is a committer, he's actually trying to do the release. We're looking at device-motion, dialogs, vibration, and camera. However, as we go through the [release process]( https://github.com/apache/cordova-coho/blob/master/docs/plugins-rele as e-process.md ), there are a lot of things that give us pause, specifically that we're going to end up tagging each plugin rather than just the four. We're also concerned that we'll bring in unstable or not-yet-completed changes from 'master' in some of the plugins. Instead, we're trying to cherry-pick. So, we know that where the final state is supposed to be: - Each plugin that we're updating gets a new tag with a build-version bump - The branch that we submitted as the PR should become the new tag (since it was based on the previous release tag) - Then we'll go on with the rest of the publish-to-NPM work, etc. Since all of the steps are automated, is there a straightforward way to cherry-pick the individual pieces that is known and has been used before? Or are we in new territory? Thanks! -Rob and Murat -- --- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Plugins release prep: Cherry-picking plugin updates
Hey, took me a while but we're good to go with: Camera, device-motion, dialogs and vibration. Thanks! -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, May 6, 2015 12:16 PM To: dev@cordova.apache.org Subject: Re: Plugins release prep: Cherry-picking plugin updates Sounds good. Thanks Rob On Wed, May 6, 2015 at 12:04 PM, Rob Paveza rob.pav...@microsoft.com wrote: Murat is still working on the merge to master for the Camera plugin. I'll let you know when we're all squared away. -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, May 6, 2015 11:57 AM To: dev@cordova.apache.org Subject: Re: Plugins release prep: Cherry-picking plugin updates I haven't heard back. Should I move forward with those 5 plugins? file-transfer, device-motion, dialogs, vibration, and camera. I will update the process to support specific plugins release (instead of all plugins) as I work through it. On Tue, May 5, 2015 at 12:29 PM, Jesse purplecabb...@gmail.com wrote: + file-transfer so we can resolve CB-8951 @purplecabbage risingj.com On Tue, May 5, 2015 at 12:19 PM, Steven Gill stevengil...@gmail.com wrote: Hey guys, I can help you out. The process is designed for all plugins but it is pretty easy to do it for just a few. I've done it many times. If changes are on master, they shouldn't be incomplete. Any known problem with release the master branch of those plugins? We could cherry-pick, but it is just more work than probably required. Since we don't have release branches for plugins, just tags. If you guys merge changes into master, I can take over the release or at least tell you the parts to modify in the release process to make it work. -Steve On Tue, May 5, 2015 at 11:44 AM, Rob Paveza rob.pav...@microsoft.com wrote: Hi all - I started a [discuss] thread about plugin updates last week, effectively saying that we wanted to take four JIRA items which are causing problems for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943. Since Murat is a committer, he's actually trying to do the release. We're looking at device-motion, dialogs, vibration, and camera. However, as we go through the [release process]( https://github.com/apache/cordova-coho/blob/master/docs/plugins-rele as e-process.md ), there are a lot of things that give us pause, specifically that we're going to end up tagging each plugin rather than just the four. We're also concerned that we'll bring in unstable or not-yet-completed changes from 'master' in some of the plugins. Instead, we're trying to cherry-pick. So, we know that where the final state is supposed to be: - Each plugin that we're updating gets a new tag with a build-version bump - The branch that we submitted as the PR should become the new tag (since it was based on the previous release tag) - Then we'll go on with the rest of the publish-to-NPM work, etc. Since all of the steps are automated, is there a straightforward way to cherry-pick the individual pieces that is known and has been used before? Or are we in new territory? Thanks! -Rob and Murat -- --- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Plugins release prep: Cherry-picking plugin updates
I haven't heard back. Should I move forward with those 5 plugins? file-transfer, device-motion, dialogs, vibration, and camera. I will update the process to support specific plugins release (instead of all plugins) as I work through it. On Tue, May 5, 2015 at 12:29 PM, Jesse purplecabb...@gmail.com wrote: + file-transfer so we can resolve CB-8951 @purplecabbage risingj.com On Tue, May 5, 2015 at 12:19 PM, Steven Gill stevengil...@gmail.com wrote: Hey guys, I can help you out. The process is designed for all plugins but it is pretty easy to do it for just a few. I've done it many times. If changes are on master, they shouldn't be incomplete. Any known problem with release the master branch of those plugins? We could cherry-pick, but it is just more work than probably required. Since we don't have release branches for plugins, just tags. If you guys merge changes into master, I can take over the release or at least tell you the parts to modify in the release process to make it work. -Steve On Tue, May 5, 2015 at 11:44 AM, Rob Paveza rob.pav...@microsoft.com wrote: Hi all - I started a [discuss] thread about plugin updates last week, effectively saying that we wanted to take four JIRA items which are causing problems for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943. Since Murat is a committer, he's actually trying to do the release. We're looking at device-motion, dialogs, vibration, and camera. However, as we go through the [release process]( https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md ), there are a lot of things that give us pause, specifically that we're going to end up tagging each plugin rather than just the four. We're also concerned that we'll bring in unstable or not-yet-completed changes from 'master' in some of the plugins. Instead, we're trying to cherry-pick. So, we know that where the final state is supposed to be: - Each plugin that we're updating gets a new tag with a build-version bump - The branch that we submitted as the PR should become the new tag (since it was based on the previous release tag) - Then we'll go on with the rest of the publish-to-NPM work, etc. Since all of the steps are automated, is there a straightforward way to cherry-pick the individual pieces that is known and has been used before? Or are we in new territory? Thanks! -Rob and Murat - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Plugins release prep: Cherry-picking plugin updates
Hey guys, I can help you out. The process is designed for all plugins but it is pretty easy to do it for just a few. I've done it many times. If changes are on master, they shouldn't be incomplete. Any known problem with release the master branch of those plugins? We could cherry-pick, but it is just more work than probably required. Since we don't have release branches for plugins, just tags. If you guys merge changes into master, I can take over the release or at least tell you the parts to modify in the release process to make it work. -Steve On Tue, May 5, 2015 at 11:44 AM, Rob Paveza rob.pav...@microsoft.com wrote: Hi all - I started a [discuss] thread about plugin updates last week, effectively saying that we wanted to take four JIRA items which are causing problems for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943. Since Murat is a committer, he's actually trying to do the release. We're looking at device-motion, dialogs, vibration, and camera. However, as we go through the [release process]( https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md), there are a lot of things that give us pause, specifically that we're going to end up tagging each plugin rather than just the four. We're also concerned that we'll bring in unstable or not-yet-completed changes from 'master' in some of the plugins. Instead, we're trying to cherry-pick. So, we know that where the final state is supposed to be: - Each plugin that we're updating gets a new tag with a build-version bump - The branch that we submitted as the PR should become the new tag (since it was based on the previous release tag) - Then we'll go on with the rest of the publish-to-NPM work, etc. Since all of the steps are automated, is there a straightforward way to cherry-pick the individual pieces that is known and has been used before? Or are we in new territory? Thanks! -Rob and Murat - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Plugins release prep: Cherry-picking plugin updates
+ file-transfer so we can resolve CB-8951 @purplecabbage risingj.com On Tue, May 5, 2015 at 12:19 PM, Steven Gill stevengil...@gmail.com wrote: Hey guys, I can help you out. The process is designed for all plugins but it is pretty easy to do it for just a few. I've done it many times. If changes are on master, they shouldn't be incomplete. Any known problem with release the master branch of those plugins? We could cherry-pick, but it is just more work than probably required. Since we don't have release branches for plugins, just tags. If you guys merge changes into master, I can take over the release or at least tell you the parts to modify in the release process to make it work. -Steve On Tue, May 5, 2015 at 11:44 AM, Rob Paveza rob.pav...@microsoft.com wrote: Hi all - I started a [discuss] thread about plugin updates last week, effectively saying that we wanted to take four JIRA items which are causing problems for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943. Since Murat is a committer, he's actually trying to do the release. We're looking at device-motion, dialogs, vibration, and camera. However, as we go through the [release process]( https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md ), there are a lot of things that give us pause, specifically that we're going to end up tagging each plugin rather than just the four. We're also concerned that we'll bring in unstable or not-yet-completed changes from 'master' in some of the plugins. Instead, we're trying to cherry-pick. So, we know that where the final state is supposed to be: - Each plugin that we're updating gets a new tag with a build-version bump - The branch that we submitted as the PR should become the new tag (since it was based on the previous release tag) - Then we'll go on with the rest of the publish-to-NPM work, etc. Since all of the steps are automated, is there a straightforward way to cherry-pick the individual pieces that is known and has been used before? Or are we in new territory? Thanks! -Rob and Murat - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Plugins Release blog post draft
wait wait, a cordova organization on github with push access!? Thats like, useful! (and blasphemy) On Thu, Aug 7, 2014 at 9:33 PM, Andrew Grieve agri...@chromium.org wrote: LGTM On Thu, Aug 7, 2014 at 7:17 PM, Steven Gill stevengil...@gmail.com wrote: Please review and send PRs for changes. I can also add you to the repo if you want to edit directly on github and not worry about the PR. https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
Re: Plugins Release blog post draft
LGTM On Fri, Aug 8, 2014 at 8:22 AM, Michal Mocny mmo...@chromium.org wrote: wait wait, a cordova organization on github with push access!? Thats like, useful! (and blasphemy) On Thu, Aug 7, 2014 at 9:33 PM, Andrew Grieve agri...@chromium.org wrote: LGTM On Thu, Aug 7, 2014 at 7:17 PM, Steven Gill stevengil...@gmail.com wrote: Please review and send PRs for changes. I can also add you to the repo if you want to edit directly on github and not worry about the PR. https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
Re: Plugins Release blog post draft
Hahaha. Michal, we pretty much only use it to preview blog posts board reports. I sent you an invite to it. On Fri, Aug 8, 2014 at 9:57 AM, Bryan Higgins br...@bryanhiggins.net wrote: LGTM On Fri, Aug 8, 2014 at 8:22 AM, Michal Mocny mmo...@chromium.org wrote: wait wait, a cordova organization on github with push access!? Thats like, useful! (and blasphemy) On Thu, Aug 7, 2014 at 9:33 PM, Andrew Grieve agri...@chromium.org wrote: LGTM On Thu, Aug 7, 2014 at 7:17 PM, Steven Gill stevengil...@gmail.com wrote: Please review and send PRs for changes. I can also add you to the repo if you want to edit directly on github and not worry about the PR. https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
Re: Plugins Release blog post draft
Typo in Ubuntu: fix compler warnings Axel Am 08.08.2014 00:18 schrieb Steven Gill stevengil...@gmail.com: Please review and send PRs for changes. I can also add you to the repo if you want to edit directly on github and not worry about the PR. https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
Re: Plugins Release blog post draft
Fixed! Thanks On Fri, Aug 8, 2014 at 11:58 AM, Axel Nennker ignisvul...@gmail.com wrote: Typo in Ubuntu: fix compler warnings Axel Am 08.08.2014 00:18 schrieb Steven Gill stevengil...@gmail.com: Please review and send PRs for changes. I can also add you to the repo if you want to edit directly on github and not worry about the PR. https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
Re: Plugins Release blog post draft
LGTM On Thu, Aug 7, 2014 at 7:17 PM, Steven Gill stevengil...@gmail.com wrote: Please review and send PRs for changes. I can also add you to the repo if you want to edit directly on github and not worry about the PR. https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
Re: Plugins Release Blog Post Review!
Nice work. Clean up extended notes and added re-did call-out of file changes: https://github.com/cordova/apache-blog-posts/pull/5 On Fri, Jun 6, 2014 at 7:36 PM, Steven Gill stevengil...@gmail.com wrote: Please review the blog post at https://github.com/cordova/apache-blog-posts/blob/master/2014-06-05-plugins-release.md . Send a pull request for changes. Or ask and I shall give you access to the repo. Once again, I would love some input on the notable changes section. Mainly, what else should I mention. -Steve
Re: Plugins Release!
For now, that's correct. Eventually, we'd like to have the docs in the plugins also include translations. On Tue, Feb 11, 2014 at 12:40 AM, Smith, Peter pet...@fast.au.fujitsu.comwrote: The site http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIssays quote Non-English translations of these plugin docs can be found by looking at older versions of the Cordova documentation. Use the drop-down menu at the very top-right of this site to switch versions. /quote I assume the English version of the docs for the plugin is correct for the latest version of that plugin. But IIUC doesn't that quote above mean (depending on plugin version changes) that the non-English docs can't really be trusted anymore because they are potentially incompatible with the actual latest plugin? It seems like the site is basically saying go to XXX where you will be able to see some outdated non-English documentation. Is that helpful? -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Tuesday, 11 February 2014 2:35 PM To: dev Subject: Re: Plugins Release! Feedback definitely welcome in this department. For the 3.4.0 release, the main docs for plugins will look like: http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden rayca...@adobe.com wrote: Is that the plan for 'core' plugins too? Won't that make it difficult for someone to see PG features as a whole? Will there be an index of some sort to make it easier to browse perhaps? Sorry for all the questions - just thinking about this from the perspective of folks *not* on this list. From: Shazron shaz...@gmail.com Sent: Monday, February 10, 2014 7:28 PM To: dev@cordova.apache.org Subject: Re: Plugins Release! The docs should be in the repo for the plugin itself, under the docs folder: https://github.com/apache/cordova-plugin-camera/blob/master/doc/index. md We're moving the docs to the plugin repo itself I believe, to de-duplicate things. On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden rayca...@adobe.com wrote:
Re: Plugins Release!
Right now the translations are pulled from the cordova-docs project edge files. If we'll need to pull the files from a different location(s) we'll need to modify the scripts and push to our crowd translation service. We'll have to ask our translators to go through and re-translate each of the files. The system won't know that the files are the same when we change the directory structure despite the names remaining the same. All this is doable. Is the documentation for each plugin officially pulled into each of the plugin repos, yet? Lisa Seacat DeLuca Mobile Engineer | t: +415.787.4589 | ldel...@apache.org | | ldel...@us.ibm.com | lisaseacat.com | | From: Andrew Grieve agri...@chromium.org To: dev dev@cordova.apache.org Date: 02/11/2014 10:56 AM Subject:Re: Plugins Release! Sent by:agri...@google.com For now, that's correct. Eventually, we'd like to have the docs in the plugins also include translations. On Tue, Feb 11, 2014 at 12:40 AM, Smith, Peter pet...@fast.au.fujitsu.comwrote: The site http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIssays quote Non-English translations of these plugin docs can be found by looking at older versions of the Cordova documentation. Use the drop-down menu at the very top-right of this site to switch versions. /quote I assume the English version of the docs for the plugin is correct for the latest version of that plugin. But IIUC doesn't that quote above mean (depending on plugin version changes) that the non-English docs can't really be trusted anymore because they are potentially incompatible with the actual latest plugin? It seems like the site is basically saying go to XXX where you will be able to see some outdated non-English documentation. Is that helpful? -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Tuesday, 11 February 2014 2:35 PM To: dev Subject: Re: Plugins Release! Feedback definitely welcome in this department. For the 3.4.0 release, the main docs for plugins will look like: http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden rayca...@adobe.com wrote: Is that the plan for 'core' plugins too? Won't that make it difficult for someone to see PG features as a whole? Will there be an index of some sort to make it easier to browse perhaps? Sorry for all the questions - just thinking about this from the perspective of folks *not* on this list. From: Shazron shaz...@gmail.com Sent: Monday, February 10, 2014 7:28 PM To: dev@cordova.apache.org Subject: Re: Plugins Release! The docs should be in the repo for the plugin itself, under the docs folder: https://github.com/apache/cordova-plugin-camera/blob/master/doc/index. md We're moving the docs to the plugin repo itself I believe, to de-duplicate things. On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden rayca...@adobe.com wrote:
Re: Plugins Release!
shipped. http://cordova.apache.org/news/2014/02/10/plugins-release.html On Sat, Feb 8, 2014 at 8:43 AM, Andrew Grieve agri...@chromium.org wrote: ship it. On Fri, Feb 7, 2014 at 7:35 PM, Steven Gill stevengil...@gmail.com wrote: ship it? On Fri, Feb 7, 2014 at 12:03 PM, Steven Gill stevengil...@gmail.com wrote: Thanks for the feedback Ian! Just waiting on the SHIP IT Updated blog below: --- layout: post author: name: Steve Gill url: https://twitter.com/stevesgill title: Plugins Release: Feb 7, 2014 categories: news tags: release --- The following plugins were updated today: * org.apache.cordova.battery-status@0.2.7 * org.apache.cordova.camera@0.2.7 * org.apache.cordova.console@0.2.7 * org.apache.cordova.contacts@0.2.8 * org.apache.cordova.device@0.2.8 * org.apache.cordova.device-motion@0.2.6 * org.apache.cordova.device-orientation@0.3.5 * org.apache.cordova.dialogs@0.2.6 * org.apache.cordova.file@1.0.0 * org.apache.cordova.file-transfer@0.4.1 * org.apache.cordova.geolocation@0.3.6 * org.apache.cordova.globalization@0.2.6 * org.apache.cordova.inappbrowser@0.3.1 * org.apache.cordova.media@0.2.8 * org.apache.cordova.media-capture@0.2.7 * org.apache.cordova.network-information@0.2.7 * org.apache.cordova.vibration@0.3.7 The most noticeable changes in this release are to the File plugin. It has been revamped to use a new URL scheme `cdvfile://localhost/filesystemType/path to file`. These URLs are generated by all file operations, and are passed over the bridge to native code. (This is in contrast to the previous version, which passed around absolute paths on the device filesystem). Most of these changes are to bring us more in line with the HTML Filesystem standard, although they will also allow us to extend the filesystem abstraction to cover new kinds of storage, both internal and external to devices. Other changes include: !--more-- * The file plugin is now much more modular. The Filesystem is now an abstract class that developers can subclass to write their own filesystem types. * Developers can use the existing filesystem types, or new types, to provide new filesystem roots for their applications. (No longer limited to just persistent and temporary, or just a single directory for storage.) * Filesystem URLs paths are now relative to the filesystem root, helping to sandbox the filesystems and keep applications from stepping on each others' toes. * Application developers can now configure the file plugin to use a more sensible location for storing persistent files. On iOS, this means storing files in the Library directory, rather than the Documents directory. On Android, it means using the application's internal storage directory rather than the SD card partition. See the README file for information on configuring your applications. * Several other bugs have been fixed, and our test coverage has increased. `org.apache.cordova.battery-status` * Add Tizen plugin support `org.apache.cordova.camera` * CB-4919 firefox os quirks added and supported platforms list is updated * getPicture via web activities * Documented quirk for CB-5335 + CB-5206 for WP7+8 * reference the correct firefoxos implementation * [BlackBerry10] Add permission to access_shared `org.apache.cordova.console` * Native console needs to be called DebugConsole to avoid ambiguous reference. This commit requires the 3.4.0 version of the native class factory * CB-4718 fixed Console plugin not working on wp `org.apache.cordova.contacts` * [CB-3208] FFOS docs updated * CB-4590 - chooseContact in CDVContacts crashes app `org.apache.cordova.device` * Tizen support added `org.apache.cordova.device-motion` * Add Tizen support `org.apache.cordova.device-orientation` * [ubuntu] request sensors permission * [ubuntu] add missing files * Add support for Tizen. * FFOS info added `org.apache.cordova.dialogs` * no need to recreate the manifest.webapp file after each `cordova prepare` for FFOS * FFOS description added `org.apache.cordova.file` * CB-5974: Use safe 'Compatibility' mode by default * CB-5915: Add option for new persistent storage location for iOS * CB-5916: Add option for new persistent storage location for Android * Add default FS root to new FS objects * CB-5899: Make DirectoryReader.readEntries return properly formatted Entry objects * Add constructor params to FileUploadResult related to CB-2421 * Fill out filesystem attribute of entities returned from resolveLocalFileSystemURL * Android: Expose filePlugin getter so that other plugins can register filesystems * Add backwards-compatibility shim for file-transfer * Android: Allow third-party plugin
RE: Plugins Release!
Dumb question, but when I see things like this in the blog post: org.apache.cordova.camera CB-4919 firefox os quirks added and supported platforms list is updated Where is that actually documented? Since I've seen quirks listed in the main doc I assumed it would be there, but I do not see it here: http://cordova.apache.org/docs/en/3.3.0/cordova_camera_camera.md.html#Camera From: Steven Gill stevengil...@gmail.com Sent: Monday, February 10, 2014 5:53 PM To: dev@cordova.apache.org Subject: Re: Plugins Release! shipped. http://cordova.apache.org/news/2014/02/10/plugins-release.html On Sat, Feb 8, 2014 at 8:43 AM, Andrew Grieve agri...@chromium.org wrote: ship it. On Fri, Feb 7, 2014 at 7:35 PM, Steven Gill stevengil...@gmail.com wrote: ship it?
Re: Plugins Release!
The docs should be in the repo for the plugin itself, under the docs folder: https://github.com/apache/cordova-plugin-camera/blob/master/doc/index.md We're moving the docs to the plugin repo itself I believe, to de-duplicate things. On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden rayca...@adobe.com wrote: Dumb question, but when I see things like this in the blog post: org.apache.cordova.camera CB-4919 firefox os quirks added and supported platforms list is updated Where is that actually documented? Since I've seen quirks listed in the main doc I assumed it would be there, but I do not see it here: http://cordova.apache.org/docs/en/3.3.0/cordova_camera_camera.md.html#Camera From: Steven Gill stevengil...@gmail.com Sent: Monday, February 10, 2014 5:53 PM To: dev@cordova.apache.org Subject: Re: Plugins Release! shipped. http://cordova.apache.org/news/2014/02/10/plugins-release.html On Sat, Feb 8, 2014 at 8:43 AM, Andrew Grieve agri...@chromium.org wrote: ship it. On Fri, Feb 7, 2014 at 7:35 PM, Steven Gill stevengil...@gmail.com wrote: ship it?
RE: Plugins Release!
Interesting. Um, I've got nothing to add here I guess. ;) I am curious to see what folks out there think. From: agri...@google.com agri...@google.com on behalf of Andrew Grieve agri...@chromium.org Sent: Monday, February 10, 2014 9:34 PM To: dev Subject: Re: Plugins Release! Feedback definitely welcome in this department. For the 3.4.0 release, the main docs for plugins will look like: http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden rayca...@adobe.com wrote:
RE: Plugins Release!
The site http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs says quote Non-English translations of these plugin docs can be found by looking at older versions of the Cordova documentation. Use the drop-down menu at the very top-right of this site to switch versions. /quote I assume the English version of the docs for the plugin is correct for the latest version of that plugin. But IIUC doesn't that quote above mean (depending on plugin version changes) that the non-English docs can't really be trusted anymore because they are potentially incompatible with the actual latest plugin? It seems like the site is basically saying go to XXX where you will be able to see some outdated non-English documentation. Is that helpful? -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Tuesday, 11 February 2014 2:35 PM To: dev Subject: Re: Plugins Release! Feedback definitely welcome in this department. For the 3.4.0 release, the main docs for plugins will look like: http://cordova.apache.org/docs/en/edge/cordova_plugins_pluginapis.md.html#Plugin%20APIs On Mon, Feb 10, 2014 at 10:07 PM, Ray Camden rayca...@adobe.com wrote: Is that the plan for 'core' plugins too? Won't that make it difficult for someone to see PG features as a whole? Will there be an index of some sort to make it easier to browse perhaps? Sorry for all the questions - just thinking about this from the perspective of folks *not* on this list. From: Shazron shaz...@gmail.com Sent: Monday, February 10, 2014 7:28 PM To: dev@cordova.apache.org Subject: Re: Plugins Release! The docs should be in the repo for the plugin itself, under the docs folder: https://github.com/apache/cordova-plugin-camera/blob/master/doc/index. md We're moving the docs to the plugin repo itself I believe, to de-duplicate things. On Mon, Feb 10, 2014 at 5:14 PM, Ray Camden rayca...@adobe.com wrote:
Re: Plugins Release!
ship it. On Fri, Feb 7, 2014 at 7:35 PM, Steven Gill stevengil...@gmail.com wrote: ship it? On Fri, Feb 7, 2014 at 12:03 PM, Steven Gill stevengil...@gmail.com wrote: Thanks for the feedback Ian! Just waiting on the SHIP IT Updated blog below: --- layout: post author: name: Steve Gill url: https://twitter.com/stevesgill title: Plugins Release: Feb 7, 2014 categories: news tags: release --- The following plugins were updated today: * org.apache.cordova.battery-status@0.2.7 * org.apache.cordova.camera@0.2.7 * org.apache.cordova.console@0.2.7 * org.apache.cordova.contacts@0.2.8 * org.apache.cordova.device@0.2.8 * org.apache.cordova.device-motion@0.2.6 * org.apache.cordova.device-orientation@0.3.5 * org.apache.cordova.dialogs@0.2.6 * org.apache.cordova.file@1.0.0 * org.apache.cordova.file-transfer@0.4.1 * org.apache.cordova.geolocation@0.3.6 * org.apache.cordova.globalization@0.2.6 * org.apache.cordova.inappbrowser@0.3.1 * org.apache.cordova.media@0.2.8 * org.apache.cordova.media-capture@0.2.7 * org.apache.cordova.network-information@0.2.7 * org.apache.cordova.vibration@0.3.7 The most noticeable changes in this release are to the File plugin. It has been revamped to use a new URL scheme `cdvfile://localhost/filesystemType/path to file`. These URLs are generated by all file operations, and are passed over the bridge to native code. (This is in contrast to the previous version, which passed around absolute paths on the device filesystem). Most of these changes are to bring us more in line with the HTML Filesystem standard, although they will also allow us to extend the filesystem abstraction to cover new kinds of storage, both internal and external to devices. Other changes include: !--more-- * The file plugin is now much more modular. The Filesystem is now an abstract class that developers can subclass to write their own filesystem types. * Developers can use the existing filesystem types, or new types, to provide new filesystem roots for their applications. (No longer limited to just persistent and temporary, or just a single directory for storage.) * Filesystem URLs paths are now relative to the filesystem root, helping to sandbox the filesystems and keep applications from stepping on each others' toes. * Application developers can now configure the file plugin to use a more sensible location for storing persistent files. On iOS, this means storing files in the Library directory, rather than the Documents directory. On Android, it means using the application's internal storage directory rather than the SD card partition. See the README file for information on configuring your applications. * Several other bugs have been fixed, and our test coverage has increased. `org.apache.cordova.battery-status` * Add Tizen plugin support `org.apache.cordova.camera` * CB-4919 firefox os quirks added and supported platforms list is updated * getPicture via web activities * Documented quirk for CB-5335 + CB-5206 for WP7+8 * reference the correct firefoxos implementation * [BlackBerry10] Add permission to access_shared `org.apache.cordova.console` * Native console needs to be called DebugConsole to avoid ambiguous reference. This commit requires the 3.4.0 version of the native class factory * CB-4718 fixed Console plugin not working on wp `org.apache.cordova.contacts` * [CB-3208] FFOS docs updated * CB-4590 - chooseContact in CDVContacts crashes app `org.apache.cordova.device` * Tizen support added `org.apache.cordova.device-motion` * Add Tizen support `org.apache.cordova.device-orientation` * [ubuntu] request sensors permission * [ubuntu] add missing files * Add support for Tizen. * FFOS info added `org.apache.cordova.dialogs` * no need to recreate the manifest.webapp file after each `cordova prepare` for FFOS * FFOS description added `org.apache.cordova.file` * CB-5974: Use safe 'Compatibility' mode by default * CB-5915: Add option for new persistent storage location for iOS * CB-5916: Add option for new persistent storage location for Android * Add default FS root to new FS objects * CB-5899: Make DirectoryReader.readEntries return properly formatted Entry objects * Add constructor params to FileUploadResult related to CB-2421 * Fill out filesystem attribute of entities returned from resolveLocalFileSystemURL * Android: Expose filePlugin getter so that other plugins can register filesystems * Add backwards-compatibility shim for file-transfer * Android: Allow third-party plugin registration * CB-5810 [BlackBerry10] resolve local:/// paths (application assets) * CB-5774: create DirectoryEntry instead of FileEntry * Initial fix for CB-5747: Windows 8: DirectoryEntry.getDirectory fails when path contains directory separator * Android: Allow absolute paths on
Re: Plugins Release!
Thanks for the feedback Ian! Just waiting on the SHIP IT Updated blog below: --- layout: post author: name: Steve Gill url: https://twitter.com/stevesgill title: Plugins Release: Feb 7, 2014 categories: news tags: release --- The following plugins were updated today: * org.apache.cordova.battery-status@0.2.7 * org.apache.cordova.camera@0.2.7 * org.apache.cordova.console@0.2.7 * org.apache.cordova.contacts@0.2.8 * org.apache.cordova.device@0.2.8 * org.apache.cordova.device-motion@0.2.6 * org.apache.cordova.device-orientation@0.3.5 * org.apache.cordova.dialogs@0.2.6 * org.apache.cordova.file@1.0.0 * org.apache.cordova.file-transfer@0.4.1 * org.apache.cordova.geolocation@0.3.6 * org.apache.cordova.globalization@0.2.6 * org.apache.cordova.inappbrowser@0.3.1 * org.apache.cordova.media@0.2.8 * org.apache.cordova.media-capture@0.2.7 * org.apache.cordova.network-information@0.2.7 * org.apache.cordova.vibration@0.3.7 The most noticeable changes in this release are to the File plugin. It has been revamped to use a new URL scheme `cdvfile://localhost/filesystemType/path to file`. These URLs are generated by all file operations, and are passed over the bridge to native code. (This is in contrast to the previous version, which passed around absolute paths on the device filesystem). Most of these changes are to bring us more in line with the HTML Filesystem standard, although they will also allow us to extend the filesystem abstraction to cover new kinds of storage, both internal and external to devices. Other changes include: !--more-- * The file plugin is now much more modular. The Filesystem is now an abstract class that developers can subclass to write their own filesystem types. * Developers can use the existing filesystem types, or new types, to provide new filesystem roots for their applications. (No longer limited to just persistent and temporary, or just a single directory for storage.) * Filesystem URLs paths are now relative to the filesystem root, helping to sandbox the filesystems and keep applications from stepping on each others' toes. * Application developers can now configure the file plugin to use a more sensible location for storing persistent files. On iOS, this means storing files in the Library directory, rather than the Documents directory. On Android, it means using the application's internal storage directory rather than the SD card partition. See the README file for information on configuring your applications. * Several other bugs have been fixed, and our test coverage has increased. `org.apache.cordova.battery-status` * Add Tizen plugin support `org.apache.cordova.camera` * CB-4919 firefox os quirks added and supported platforms list is updated * getPicture via web activities * Documented quirk for CB-5335 + CB-5206 for WP7+8 * reference the correct firefoxos implementation * [BlackBerry10] Add permission to access_shared `org.apache.cordova.console` * Native console needs to be called DebugConsole to avoid ambiguous reference. This commit requires the 3.4.0 version of the native class factory * CB-4718 fixed Console plugin not working on wp `org.apache.cordova.contacts` * [CB-3208] FFOS docs updated * CB-4590 - chooseContact in CDVContacts crashes app `org.apache.cordova.device` * Tizen support added `org.apache.cordova.device-motion` * Add Tizen support `org.apache.cordova.device-orientation` * [ubuntu] request sensors permission * [ubuntu] add missing files * Add support for Tizen. * FFOS info added `org.apache.cordova.dialogs` * no need to recreate the manifest.webapp file after each `cordova prepare` for FFOS * FFOS description added `org.apache.cordova.file` * CB-5974: Use safe 'Compatibility' mode by default * CB-5915: Add option for new persistent storage location for iOS * CB-5916: Add option for new persistent storage location for Android * Add default FS root to new FS objects * CB-5899: Make DirectoryReader.readEntries return properly formatted Entry objects * Add constructor params to FileUploadResult related to CB-2421 * Fill out filesystem attribute of entities returned from resolveLocalFileSystemURL * Android: Expose filePlugin getter so that other plugins can register filesystems * Add backwards-compatibility shim for file-transfer * Android: Allow third-party plugin registration * CB-5810 [BlackBerry10] resolve local:/// paths (application assets) * CB-5774: create DirectoryEntry instead of FileEntry * Initial fix for CB-5747: Windows 8: DirectoryEntry.getDirectory fails when path contains directory separator * Android: Allow absolute paths on Entry.getFile / Entry.getDirectory * CB-5008: Rename resolveLocalFileSystemURI to resolveLocalFileSystemURL * CB-4899 [BlackBerry10] Fix resolve directories * CB-5602 Windows8. Fix File Api mobile spec tests * Android: Better support for content urls and cross-filesystem copy/move ops * CB-5699 [BlackBerry10] Update resolveLocalFileSystemURI implementation * CB-5658 Update license comment formatting of
Re: Plugins Release!
ship it? On Fri, Feb 7, 2014 at 12:03 PM, Steven Gill stevengil...@gmail.com wrote: Thanks for the feedback Ian! Just waiting on the SHIP IT Updated blog below: --- layout: post author: name: Steve Gill url: https://twitter.com/stevesgill title: Plugins Release: Feb 7, 2014 categories: news tags: release --- The following plugins were updated today: * org.apache.cordova.battery-status@0.2.7 * org.apache.cordova.camera@0.2.7 * org.apache.cordova.console@0.2.7 * org.apache.cordova.contacts@0.2.8 * org.apache.cordova.device@0.2.8 * org.apache.cordova.device-motion@0.2.6 * org.apache.cordova.device-orientation@0.3.5 * org.apache.cordova.dialogs@0.2.6 * org.apache.cordova.file@1.0.0 * org.apache.cordova.file-transfer@0.4.1 * org.apache.cordova.geolocation@0.3.6 * org.apache.cordova.globalization@0.2.6 * org.apache.cordova.inappbrowser@0.3.1 * org.apache.cordova.media@0.2.8 * org.apache.cordova.media-capture@0.2.7 * org.apache.cordova.network-information@0.2.7 * org.apache.cordova.vibration@0.3.7 The most noticeable changes in this release are to the File plugin. It has been revamped to use a new URL scheme `cdvfile://localhost/filesystemType/path to file`. These URLs are generated by all file operations, and are passed over the bridge to native code. (This is in contrast to the previous version, which passed around absolute paths on the device filesystem). Most of these changes are to bring us more in line with the HTML Filesystem standard, although they will also allow us to extend the filesystem abstraction to cover new kinds of storage, both internal and external to devices. Other changes include: !--more-- * The file plugin is now much more modular. The Filesystem is now an abstract class that developers can subclass to write their own filesystem types. * Developers can use the existing filesystem types, or new types, to provide new filesystem roots for their applications. (No longer limited to just persistent and temporary, or just a single directory for storage.) * Filesystem URLs paths are now relative to the filesystem root, helping to sandbox the filesystems and keep applications from stepping on each others' toes. * Application developers can now configure the file plugin to use a more sensible location for storing persistent files. On iOS, this means storing files in the Library directory, rather than the Documents directory. On Android, it means using the application's internal storage directory rather than the SD card partition. See the README file for information on configuring your applications. * Several other bugs have been fixed, and our test coverage has increased. `org.apache.cordova.battery-status` * Add Tizen plugin support `org.apache.cordova.camera` * CB-4919 firefox os quirks added and supported platforms list is updated * getPicture via web activities * Documented quirk for CB-5335 + CB-5206 for WP7+8 * reference the correct firefoxos implementation * [BlackBerry10] Add permission to access_shared `org.apache.cordova.console` * Native console needs to be called DebugConsole to avoid ambiguous reference. This commit requires the 3.4.0 version of the native class factory * CB-4718 fixed Console plugin not working on wp `org.apache.cordova.contacts` * [CB-3208] FFOS docs updated * CB-4590 - chooseContact in CDVContacts crashes app `org.apache.cordova.device` * Tizen support added `org.apache.cordova.device-motion` * Add Tizen support `org.apache.cordova.device-orientation` * [ubuntu] request sensors permission * [ubuntu] add missing files * Add support for Tizen. * FFOS info added `org.apache.cordova.dialogs` * no need to recreate the manifest.webapp file after each `cordova prepare` for FFOS * FFOS description added `org.apache.cordova.file` * CB-5974: Use safe 'Compatibility' mode by default * CB-5915: Add option for new persistent storage location for iOS * CB-5916: Add option for new persistent storage location for Android * Add default FS root to new FS objects * CB-5899: Make DirectoryReader.readEntries return properly formatted Entry objects * Add constructor params to FileUploadResult related to CB-2421 * Fill out filesystem attribute of entities returned from resolveLocalFileSystemURL * Android: Expose filePlugin getter so that other plugins can register filesystems * Add backwards-compatibility shim for file-transfer * Android: Allow third-party plugin registration * CB-5810 [BlackBerry10] resolve local:/// paths (application assets) * CB-5774: create DirectoryEntry instead of FileEntry * Initial fix for CB-5747: Windows 8: DirectoryEntry.getDirectory fails when path contains directory separator * Android: Allow absolute paths on Entry.getFile / Entry.getDirectory * CB-5008: Rename resolveLocalFileSystemURI to resolveLocalFileSystemURL * CB-4899 [BlackBerry10] Fix resolve directories * CB-5602 Windows8. Fix File Api mobile spec tests *
Re: Plugins Release!
plugin. * CB-5658 Delete stale snapshot of plugin docs * CB-5403: Backwards-compatibility with file:// urls where possible * CB-5407: Fixes for ContentFilesystem * Android: Add method for testing backwards-compatibility of filetransfer plugin * iOS: Add method for testing backwards-compatiblity of filetransfer plugin * Android: Updates to allow FileTransfer to continue to work * Android: Clean up unclosed file objects * CB-5407: Add new Android source files to plugin.xml * CB-5407: Move read, write and truncate methods into modules * CB-5407: Move copy/move methods into FS modules * CB-5407: Move getParent into FS modules * CB-5407: Move getmetadata methods into FS modules * CB-5407: Move readdir methods into FS modules * CB-5407: Move remove methods into FS modules * CB-5407: Move getFile into FS modules * CB-5407: Start refactoring android code: Modular filesystems, rfs, rlfsurl * CB-5407: Update android JS to use FS urls * CB-5405: Use URL formatting for Entry.toURL * Log file path for File exceptions. * Partial fix for iOS File compatibility with previous fileTransfer plugin * CB-5532 WP8. Add binary data support to FileWriter * CB-5531 WP8. File Api readAsText incorrectly handles position args * Added ubuntu platform support * Added amazon-fireos platform support * CB-5118 [BlackBerry10] Add check for undefined error handler * CB-5406: Extend public API for dependent plugins * CB-5403: Bump File plugin major version * CB-5406: Split iOS file plugin into modules * CB-5406: Factor out filesystem providers in iOS * CB-5408: Add handler for filesystem:// urls * CB-5406: Update iOS native code to use filesystem URLs internally * CB-5405: Update JS code to use URLs exclusively * CB-4816 Fix file creation outside sandbox for BB10 `org.apache.cordova.file-transfer@0.4.1` * CB-5365 Remove unused exception var to prevent warnings? * CB-2421 explicitly write the bytesSent,responseCode,result to the FileUploadResult pending release of cordova-plugin-file dependency, added some sanity checks for callbacks * iOS: Update for new file plugin api * CB-5631 Removed SimpleTrackingInputStream.read(byte[] buffer) * CB-5762 android: Fix lengthComputable set wrong for gzip downloads * CB-4899 [BlackBerry10] Improve binary file transfer download * CB-5722 [BlackBerry10] Update upload function to use native file object * CB-5658 Delete stale snapshot of plugin docs * CB-5466: Update to work with filesystem URLs `org.apache.cordova.geolocation` * add ubuntu platform support * CB-5326 adding FFOS permission and updating supported platforms * CB-5729 [BlackBerry10] Update GeolocationProxy to return collapsed object `org.apache.cordova.globalization` * Add Tizen plugin support `org.apache.cordova.inappbrowser` * CB-5756: Android: Use WebView.evaluateJavascript for script injection on Android 4.4+ * Didn't test on ICS or lower, getDrawable isn't supported until Jellybean * add ubuntu platform * Adding drawables to the inAppBrowser. This doesn't look quite right, but it's a HUGE improvement over the previous settings * CB-5756: Android: Use WebView.evaluateJavascript for script injection on Android 4.4+ * Remove alive from InAppBrowser.js since it didn't catch the case where the browser is closed by the user. * CB-5733 Fix IAB.close() not working if called before show() animation is done `org.apache.cordova.media` * Add preliminary support for Tizen. * [CB-4755] Fix crash in Media.setVolume on iOS `org.apache.cordova.media-capture` * [ubuntu] request audio/camera/microphone permission * fixed cordova cli add capture plugin not work wp * CB-5685 [BlackBerry10] Add access_shared permission `org.apache.cordova.network-information` * Initial implementation of Tizen plugin. `org.apache.cordova.splashscreen` * [CB-3562] Fix aspect ratio on landscape-only iPhone applications * CB-4051 fix for splashscreen rotation problem `org.apache.cordova.vibration` * Add support for Tizen. * CB-3206 - Supported platforms updated The plugins have been updated on our registry at [plugins.cordova.io]( http://plugins.cordova.io/). E.g. To update your vibration plugin: cordova plugin rm org.apache.cordova.vibration cordova plugin add org.apache.cordova.vibration On Tue, Feb 4, 2014 at 3:20 PM, Joe Bowser bows...@gmail.com wrote: Don't do it! I think File still needs some work: https://issues.apache.org/jira/browse/CB-5974 On Tue, Feb 4, 2014 at 3:18 PM, Herm Wong kingoftheo...@hotmail.com wrote: Sounds good to me! From: agri...@chromium.org Date: Tue, 4 Feb 2014 14:35:01 -0500 Subject: Re: Plugins Release! To: dev@cordova.apache.org Sounds good! On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill stevengil...@gmail.com wrote: I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
+1 to this. How about this addition: if the setting isn't explicitly declared in config.xml, log a warning but still default to exactly where they are now. On Feb 5, 2014, at 10:50 AM, Ian Clelland iclell...@chromium.org wrote: So this proposal would be: - Don't revert the changes made on dev - Don't rename the plugin - Add a default which places files exactly where they are now - Bump the major version - Start fixing bugs in the new code. (without being distracted by the storage location change) - Start blogging about the issue with storage locations, and encourage people to change (but don't force them to do anything yet) - In a year, or when we feel that a sufficient mass of developers have gotten the message, broadcast that we're removing the default. (or changing it, if we're very confident in our plugin upgrade paths) - Some months after that, make the change. (and hopefully not be distracted by bugs in the underlying plugin code) Bump the major version again.
Re: Plugins Release!
I've taken a first pass at the file plugin (I'll probably revisit it in the morning and think it's terrible :) ) On Thu, Feb 6, 2014 at 4:44 PM, Steven Gill stevengil...@gmail.com wrote: Okay, I have a blog post ready to review. I could use some help with adding more content about the file plugin release. I got most of my info for it from http://markmail.org/thread/ebm3ms6of24rhyvb. I have also gone through the commits and removed ones I thought were unimportant. If you feel more curating needs to be done, feel free to edit. The most noticeable changes in this release are to the File plugin. It has been revamped to use a new URL scheme `cdvfile://localhost/filesystemType/path to file`. These URLs are generated by all file operations, and are passed over the bridge to native code. (This is in contrast to the previous version, which passed around absolute paths on the device filesystem). Most of these changes are to bring us more in line with the HTML Filesystem standard, although they will also allow us to extend the filesystem abstraction to cover new kinds of storage, both internal and external to devices. Other changes include: * The file plugin is now much more modular. The Filesystem is now an abstract class that developers can subclass to write their own filesystem types. * Developers can use the existing filesystem types, or new types, to provide new filesystem roots for their applications. (No longer limited to just persistent and temporary, or just a single directory for storage.) * Filesystem URLs paths are now relative to the filesystem root, helping to sandbox the filesystems and keep applications from stepping on each others' toes. * Application developers can now configure the file plugin to use a more sensible location for storing persistent files. On iOS, this means storing files in the Library directory, rather than the Documents directory. On Android, it means using the application's internal storage directory rather than the SD card partition. See the README file for information on configuring your applications. * Several other bugs have been fixed, and our test coverage has increased. [Much curating of file changes; too many commits for the number of issues fixed ;) ] `org.apache.cordova.file` * CB-5974: Use safe 'Compatibility' mode by default * CB-5915: Add option for new persistent storage location for iOS * CB-5916: Add option for new persistent storage location for Android * Add default FS root to new FS objects * CB-5899: Make DirectoryReader.readEntries return properly formatted Entry objects * Add constructor params to FileUploadResult related to CB-2421 * Fill out filesystem attribute of entities returned from resolveLocalFileSystemURL * Android: Expose filePlugin getter so that other plugins can register filesystems * Add backwards-compatibility shim for file-transfer * Android: Allow third-party plugin registration * CB-5810 [BlackBerry10] resolve local:/// paths (application assets) * CB-5774: create DirectoryEntry instead of FileEntry * Initial fix for CB-5747: Windows 8: DirectoryEntry.getDirectory fails when path contains directory separator * Android: Allow absolute paths on Entry.getFile / Entry.getDirectory * CB-5008: Rename resolveLocalFileSystemURI to resolveLocalFileSystemURL * CB-4899 [BlackBerry10] Fix resolve directories * CB-5602 Windows8. Fix File Api mobile spec tests * Android: Better support for content urls and cross-filesystem copy/move ops * CB-5699 [BlackBerry10] Update resolveLocalFileSystemURI implementation * CB-5658 Update license comment formatting of doc/index.md * CB-5658 Add doc.index.md for File plugin. * CB-5658 Delete stale snapshot of plugin docs * CB-5403: Backwards-compatibility with file:// urls where possible * Android: Clean up unclosed file objects * Log file path for File exceptions. * CB-5532 WP8. Add binary data support to FileWriter * CB-5531 WP8. File Api readAsText incorrectly handles position args * Added ubuntu platform support * Added amazon-fireos platform support * CB-5118 [BlackBerry10] Add check for undefined error handler * CB-5403: Bump File plugin major version * CB-5408: Add handler for filesystem urls * CB-5407: Update Android native code to use filesystem URLs internally * CB-5406: Update iOS native code to use filesystem URLs internally * CB-5405: Update JS code to use URLs exclusively * CB-4816 Fix file creation outside sandbox for BB10
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
+1 for a warning.. Warnings are the precursors to education - me, just now On 07/02/2014 11:55 am, Marcel Kinard cmarc...@gmail.com wrote: +1 to this. How about this addition: if the setting isn't explicitly declared in config.xml, log a warning but still default to exactly where they are now. On Feb 5, 2014, at 10:50 AM, Ian Clelland iclell...@chromium.org wrote: So this proposal would be: - Don't revert the changes made on dev - Don't rename the plugin - Add a default which places files exactly where they are now - Bump the major version - Start fixing bugs in the new code. (without being distracted by the storage location change) - Start blogging about the issue with storage locations, and encourage people to change (but don't force them to do anything yet) - In a year, or when we feel that a sufficient mass of developers have gotten the message, broadcast that we're removing the default. (or changing it, if we're very confident in our plugin upgrade paths) - Some months after that, make the change. (and hopefully not be distracted by bugs in the underlying plugin code) Bump the major version again.
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
-1 to merging reads. That just sounds like a horrible thing to debug. +1 to 'go big or go home'. Break it now. Break it obviously. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
My concern with any automated fix is that we have no idea what files belong to an app. The default is to just toss everything in the root. Files may be user data that is shared between apps, config files or temp files. The developer probably knows what to migrate - we don't.\ On Wed, Feb 5, 2014 at 9:05 AM, sebb seb...@gmail.com wrote: On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one? It might be. The File API doesn't impose any sort of model for read/write patterns. Reads and writes can happen anywhere in a file; we can't enforce that a file is written out entirely in one call, so there may not be a point where we can say it's done; delete the old one. It's also entirely possible for multiple readers to be open on the file, and for another thread to have a writer open, writing somewhere in the middle of the file, so I would expect race conditions. This isn't *impossible*; there have been OS filesystems which do this for a long time, but it seems to me to be a lot more work than writing a tool for developers to use for migration, and much more error prone.
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On 5 February 2014 14:55, David Kemp drk...@google.com wrote: My concern with any automated fix is that we have no idea what files belong to an app. The default is to just toss everything in the root. Files may be user data that is shared between apps, config files or temp files. The developer probably knows what to migrate - we don't.\ The app must tell the library what file names are involved. So unless the same API is used for files that are supposed to remain in the root, it should be possible to know what needs to move. It may still prove too difficult to implement the merge, but perhaps there is some scope for adding something to help the developers. For example, the code could check if there is a file with the same name in the old location, and log a message if so. There may be other checks that would help mitigate the breakage. On Wed, Feb 5, 2014 at 9:05 AM, sebb seb...@gmail.com wrote: On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Imagine a hypothetical implementation which works like this: Consumer asks for a file, we don't find it in Library, nor is the we're migrating file, we create the we're migrating file, it's present in Root. We start a copy in the background and return some file handle (probably a proxy). Any writes are written to the we're migrating file if that part of the file exists in addition to the original. When the copy completes, we rename we're migrating to the correct file. Then we delete the original. Ian wrote: It might be. The File API doesn't impose any sort of model for read/write patterns. Reads and writes can happen anywhere in a file; we can't enforce that a file is written out entirely in one call, so there may not be a point where we can say it's done; delete the old one. It's also entirely possible for multiple readers to be open on the file, and for another thread to have a writer open, writing somewhere in the middle of the file, so I would expect race conditions. This isn't *impossible*; there have been OS filesystems which do this for a long time, but it seems to me to be a lot more work than writing a tool for developers to use for migration, and much more error prone. Perhaps we should start with that. Shouldn't someone write a tool which scans for consumers and offers a survey and let's the developer pick an answer with which it rewrites the file?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Honestly, my opinion on this: Leave the default as-is for now. We've just made huge changes to the API, which may have bugs / implications we haven't fully thought through. Lets let a subset of users upgrade to the new $MAJOR version, and a subset of those add the new preference. In a later release, we can make the switch -- by then, maybe we will have more solutions for migrating. Also, this is a nice to have, but its obviously been a situation that devs have been living with for years. -Michal On Wed, Feb 5, 2014 at 10:13 AM, sebb seb...@gmail.com wrote: On 5 February 2014 14:55, David Kemp drk...@google.com wrote: My concern with any automated fix is that we have no idea what files belong to an app. The default is to just toss everything in the root. Files may be user data that is shared between apps, config files or temp files. The developer probably knows what to migrate - we don't.\ The app must tell the library what file names are involved. So unless the same API is used for files that are supposed to remain in the root, it should be possible to know what needs to move. It may still prove too difficult to implement the merge, but perhaps there is some scope for adding something to help the developers. For example, the code could check if there is a file with the same name in the old location, and log a message if so. There may be other checks that would help mitigate the breakage. On Wed, Feb 5, 2014 at 9:05 AM, sebb seb...@gmail.com wrote: On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
I also think we should break it now. It's not as if we have never broken anything before... keeping backward compatibility should anyways be preferred but in this case I think it would cause more trouble than it would solve. I say don't write any migration tools but document the changes in plugin.xml (info tag), write a blog post about it, tweet it, Google plus it and... Be super loud about it. It's not like we are breaking everything for everyone either. We have plugin versions for a reason. Another way of avoiding this would have been to pick a different name for this plugin. Is it too late? On Feb 5, 2014 7:03 AM, Ian Clelland iclell...@google.com wrote: On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one? It might be. The File API doesn't impose any sort of model for read/write patterns. Reads and writes can happen anywhere in a file; we can't enforce that a file is written out entirely in one call, so there may not be a point where we can say it's done; delete the old one. It's also entirely possible for multiple readers to be open on the file, and for another thread to have a writer open, writing somewhere in the middle of the file, so I would expect race conditions. This isn't *impossible*; there have been OS filesystems which do this for a long time, but it seems to me to be a lot more work than writing a tool for developers to use for migration, and much more error prone.
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On Wed, Feb 5, 2014 at 10:29 AM, Anis KADRI anis.ka...@gmail.com wrote: I also think we should break it now. It's not as if we have never broken anything before... keeping backward compatibility should anyways be preferred but in this case I think it would cause more trouble than it would solve. I say don't write any migration tools but document the changes in plugin.xml (info tag), write a blog post about it, tweet it, Google plus it and... Be super loud about it. It's not like we are breaking everything for everyone either. We have plugin versions for a reason. Right, this was going to be the first test of a major version bump of a published plugin. We want this to be a step that developers need to take deliberately, I think. Another way of avoiding this would have been to pick a different name for this plugin. Is it too late? Not too late; it would be some work to cherry-pick the unrelated fixes from dev, but we could do it. Maybe we should do that anyway, and maintain an 0.x line for people who won't/cant' upgrade. Ian On Feb 5, 2014 7:03 AM, Ian Clelland iclell...@google.com wrote: On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one? It might be. The File API doesn't impose any sort of model for read/write patterns. Reads and writes can happen anywhere in a file; we can't enforce that a file is written out entirely in one call, so there may not be a point where we can say it's done; delete the old one. It's also entirely possible for multiple readers to be open on the file, and for another thread to have a writer open, writing somewhere in the middle of the file, so I would expect race conditions. This isn't *impossible*; there have been OS filesystems which do this for a long time, but it seems to me to be a lot more work than writing a tool for developers to use for migration, and much more error prone.
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny mmo...@chromium.org wrote: Honestly, my opinion on this: Leave the default as-is for now. We've just made huge changes to the API, which may have bugs / implications we haven't fully thought through. That's a really good point. If we do this right now, we have two huge changes going on at the same time, and we will have to deal with a lot of heat for bugs *as well* as the location change. Lets let a subset of users upgrade to the new $MAJOR version, and a subset of those add the new preference. In a later release, we can make the switch -- by then, maybe we will have more solutions for migrating. Also, this is a nice to have, but its obviously been a situation that devs have been living with for years. That is something that I was thinking about last night. If we go with #3; put in a safe default, then we could spend a year if we wanted to promoting hard the please please please switch to the better version position. Then we could announce long in advance that we're changing the default, or that we're removing the default, and when we're ready, bump the major again to 2.x and do it. This might be the best situation for the developers, and it's no worse for the users than the situation right now. It's less than optimal for the cordova ecosystem, but the ecosystem may be harmed more by angry developers leaving the platform than by continuing to place files where they are now. So this proposal would be: - Don't revert the changes made on dev - Don't rename the plugin - Add a default which places files exactly where they are now - Bump the major version - Start fixing bugs in the new code. (without being distracted by the storage location change) - Start blogging about the issue with storage locations, and encourage people to change (but don't force them to do anything yet) - In a year, or when we feel that a sufficient mass of developers have gotten the message, broadcast that we're removing the default. (or changing it, if we're very confident in our plugin upgrade paths) - Some months after that, make the change. (and hopefully not be distracted by bugs in the underlying plugin code) Bump the major version again. I'm actually pretty happy with that; we think that the current situation isn't great, but it doesn't seem to be actively hurting the ecosystem. And any developers who think otherwise will now have the tools to fix it for their own apps. Eventually we can be more opinionated about it, and the plugin will be more robust, so devs shouldn't be *as* angry as if we switched it right now. Ian -Michal On Wed, Feb 5, 2014 at 10:13 AM, sebb seb...@gmail.com wrote: On 5 February 2014 14:55, David Kemp drk...@google.com wrote: My concern with any automated fix is that we have no idea what files belong to an app. The default is to just toss everything in the root. Files may be user data that is shared between apps, config files or temp files. The developer probably knows what to migrate - we don't.\ The app must tell the library what file names are involved. So unless the same API is used for files that are supposed to remain in the root, it should be possible to know what needs to move. It may still prove too difficult to implement the merge, but perhaps there is some scope for adding something to help the developers. For example, the code could check if there is a file with the same name in the old location, and log a message if so. There may be other checks that would help mitigate the breakage. On Wed, Feb 5, 2014 at 9:05 AM, sebb seb...@gmail.com wrote: On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
I couldn't have said it better myself. -1 to just break it. On Wed, Feb 5, 2014 at 8:00 AM, Tommy Williams to...@devgeeks.org wrote: -1 to just break it Developers using Cordova still are frequently having to deal with massive breaking changes every few releases. Developing and (even more so) maintaining an app built using Cordova is actually pretty painful sometimes... Even for me, and I am on this list and see this stuff coming. If you think the new way is the best one true way, then leave the default as is and *educate* people as to why. The File API is one of the *most* used plugins of the core plugins. Breaking that big a percentage of existing apps at 3.4 seems unwise to me. I know, I know... The plugins are separately versioned and this will be a major version change.. Tell me, has any dev had to know or really even been exposed to the fact that the plugins have their own versions yet? It's not like we have a package.json file with deps in it all semvered based on last known good versions like a node app might. I doubt many devs even know you *can* install a particular version of a plugin. If when installing a plugin we had --save-deps or something, and that used versions and kind of pinned the app to that major version, then a breaking version change might not break as many hearts ;) - tommy On 06/02/2014 2:26 am, Michal Mocny mmo...@chromium.org wrote: Honestly, my opinion on this: Leave the default as-is for now. We've just made huge changes to the API, which may have bugs / implications we haven't fully thought through. Lets let a subset of users upgrade to the new $MAJOR version, and a subset of those add the new preference. In a later release, we can make the switch -- by then, maybe we will have more solutions for migrating. Also, this is a nice to have, but its obviously been a situation that devs have been living with for years. -Michal On Wed, Feb 5, 2014 at 10:13 AM, sebb seb...@gmail.com wrote: On 5 February 2014 14:55, David Kemp drk...@google.com wrote: My concern with any automated fix is that we have no idea what files belong to an app. The default is to just toss everything in the root. Files may be user data that is shared between apps, config files or temp files. The developer probably knows what to migrate - we don't.\ The app must tell the library what file names are involved. So unless the same API is used for files that are supposed to remain in the root, it should be possible to know what needs to move. It may still prove too difficult to implement the merge, but perhaps there is some scope for adding something to help the developers. For example, the code could check if there is a file with the same name in the old location, and log a message if so. There may be other checks that would help mitigate the breakage. On Wed, Feb 5, 2014 at 9:05 AM, sebb seb...@gmail.com wrote: On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Of course, while writing my rant, Ian has summarized a great proposal. +1 to the below! On 06/02/2014 2:51 am, Ian Clelland iclell...@chromium.org wrote: On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny mmo...@chromium.org wrote: Honestly, my opinion on this: Leave the default as-is for now. We've just made huge changes to the API, which may have bugs / implications we haven't fully thought through. That's a really good point. If we do this right now, we have two huge changes going on at the same time, and we will have to deal with a lot of heat for bugs *as well* as the location change. Lets let a subset of users upgrade to the new $MAJOR version, and a subset of those add the new preference. In a later release, we can make the switch -- by then, maybe we will have more solutions for migrating. Also, this is a nice to have, but its obviously been a situation that devs have been living with for years. That is something that I was thinking about last night. If we go with #3; put in a safe default, then we could spend a year if we wanted to promoting hard the please please please switch to the better version position. Then we could announce long in advance that we're changing the default, or that we're removing the default, and when we're ready, bump the major again to 2.x and do it. This might be the best situation for the developers, and it's no worse for the users than the situation right now. It's less than optimal for the cordova ecosystem, but the ecosystem may be harmed more by angry developers leaving the platform than by continuing to place files where they are now. So this proposal would be: - Don't revert the changes made on dev - Don't rename the plugin - Add a default which places files exactly where they are now - Bump the major version - Start fixing bugs in the new code. (without being distracted by the storage location change) - Start blogging about the issue with storage locations, and encourage people to change (but don't force them to do anything yet) - In a year, or when we feel that a sufficient mass of developers have gotten the message, broadcast that we're removing the default. (or changing it, if we're very confident in our plugin upgrade paths) - Some months after that, make the change. (and hopefully not be distracted by bugs in the underlying plugin code) Bump the major version again. I'm actually pretty happy with that; we think that the current situation isn't great, but it doesn't seem to be actively hurting the ecosystem. And any developers who think otherwise will now have the tools to fix it for their own apps. Eventually we can be more opinionated about it, and the plugin will be more robust, so devs shouldn't be *as* angry as if we switched it right now. Ian -Michal On Wed, Feb 5, 2014 at 10:13 AM, sebb seb...@gmail.com wrote: On 5 February 2014 14:55, David Kemp drk...@google.com wrote: My concern with any automated fix is that we have no idea what files belong to an app. The default is to just toss everything in the root. Files may be user data that is shared between apps, config files or temp files. The developer probably knows what to migrate - we don't.\ The app must tell the library what file names are involved. So unless the same API is used for files that are supposed to remain in the root, it should be possible to know what needs to move. It may still prove too difficult to implement the merge, but perhaps there is some scope for adding something to help the developers. For example, the code could check if there is a file with the same name in the old location, and log a message if so. There may be other checks that would help mitigate the breakage. On Wed, Feb 5, 2014 at 9:05 AM, sebb seb...@gmail.com wrote: On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. On Tue, Feb 4, 2014 at 11:45 PM, Josh
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Agreed! I didn't see that either until now. On Wed, Feb 5, 2014 at 8:04 AM, Tommy Williams to...@devgeeks.org wrote: Of course, while writing my rant, Ian has summarized a great proposal. +1 to the below! On 06/02/2014 2:51 am, Ian Clelland iclell...@chromium.org wrote: On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny mmo...@chromium.org wrote: Honestly, my opinion on this: Leave the default as-is for now. We've just made huge changes to the API, which may have bugs / implications we haven't fully thought through. That's a really good point. If we do this right now, we have two huge changes going on at the same time, and we will have to deal with a lot of heat for bugs *as well* as the location change. Lets let a subset of users upgrade to the new $MAJOR version, and a subset of those add the new preference. In a later release, we can make the switch -- by then, maybe we will have more solutions for migrating. Also, this is a nice to have, but its obviously been a situation that devs have been living with for years. That is something that I was thinking about last night. If we go with #3; put in a safe default, then we could spend a year if we wanted to promoting hard the please please please switch to the better version position. Then we could announce long in advance that we're changing the default, or that we're removing the default, and when we're ready, bump the major again to 2.x and do it. This might be the best situation for the developers, and it's no worse for the users than the situation right now. It's less than optimal for the cordova ecosystem, but the ecosystem may be harmed more by angry developers leaving the platform than by continuing to place files where they are now. So this proposal would be: - Don't revert the changes made on dev - Don't rename the plugin - Add a default which places files exactly where they are now - Bump the major version - Start fixing bugs in the new code. (without being distracted by the storage location change) - Start blogging about the issue with storage locations, and encourage people to change (but don't force them to do anything yet) - In a year, or when we feel that a sufficient mass of developers have gotten the message, broadcast that we're removing the default. (or changing it, if we're very confident in our plugin upgrade paths) - Some months after that, make the change. (and hopefully not be distracted by bugs in the underlying plugin code) Bump the major version again. I'm actually pretty happy with that; we think that the current situation isn't great, but it doesn't seem to be actively hurting the ecosystem. And any developers who think otherwise will now have the tools to fix it for their own apps. Eventually we can be more opinionated about it, and the plugin will be more robust, so devs shouldn't be *as* angry as if we switched it right now. Ian -Michal On Wed, Feb 5, 2014 at 10:13 AM, sebb seb...@gmail.com wrote: On 5 February 2014 14:55, David Kemp drk...@google.com wrote: My concern with any automated fix is that we have no idea what files belong to an app. The default is to just toss everything in the root. Files may be user data that is shared between apps, config files or temp files. The developer probably knows what to migrate - we don't.\ The app must tell the library what file names are involved. So unless the same API is used for files that are supposed to remain in the root, it should be possible to know what needs to move. It may still prove too difficult to implement the merge, but perhaps there is some scope for adding something to help the developers. For example, the code could check if there is a file with the same name in the old location, and log a message if so. There may be other checks that would help mitigate the breakage. On Wed, Feb 5, 2014 at 9:05 AM, sebb seb...@gmail.com wrote: On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously.
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
I think this approach is our best path forward right now. There's no immediate need to break apps for developers; it was a convenient time in the development of the plugin, but we can easily wait for another convenient time. There seems to be no compelling reason to couple a breaking change with the other updates to the plugin. I'm committing changes to the plugin now to support this; the actual set the default so things don't break code is isolated to a single commit, so that it's super easy to revert or change later if we decide we don't like it. I've asked around here, nobody on the Google team has any objections to this path. Anis, you were also agreeing with me previously about breaking sooner rather than later: Are you okay now with separating the two issues, just doing the API upgrade now, and starting the process of promoting the new locations before we change the default sometime in the next 12 months? On Wed, Feb 5, 2014 at 11:19 AM, Joe Bowser bows...@gmail.com wrote: Agreed! I didn't see that either until now. On Wed, Feb 5, 2014 at 8:04 AM, Tommy Williams to...@devgeeks.org wrote: Of course, while writing my rant, Ian has summarized a great proposal. +1 to the below! On 06/02/2014 2:51 am, Ian Clelland iclell...@chromium.org wrote: On Wed, Feb 5, 2014 at 10:25 AM, Michal Mocny mmo...@chromium.org wrote: Honestly, my opinion on this: Leave the default as-is for now. We've just made huge changes to the API, which may have bugs / implications we haven't fully thought through. That's a really good point. If we do this right now, we have two huge changes going on at the same time, and we will have to deal with a lot of heat for bugs *as well* as the location change. Lets let a subset of users upgrade to the new $MAJOR version, and a subset of those add the new preference. In a later release, we can make the switch -- by then, maybe we will have more solutions for migrating. Also, this is a nice to have, but its obviously been a situation that devs have been living with for years. That is something that I was thinking about last night. If we go with #3; put in a safe default, then we could spend a year if we wanted to promoting hard the please please please switch to the better version position. Then we could announce long in advance that we're changing the default, or that we're removing the default, and when we're ready, bump the major again to 2.x and do it. This might be the best situation for the developers, and it's no worse for the users than the situation right now. It's less than optimal for the cordova ecosystem, but the ecosystem may be harmed more by angry developers leaving the platform than by continuing to place files where they are now. So this proposal would be: - Don't revert the changes made on dev - Don't rename the plugin - Add a default which places files exactly where they are now - Bump the major version - Start fixing bugs in the new code. (without being distracted by the storage location change) - Start blogging about the issue with storage locations, and encourage people to change (but don't force them to do anything yet) - In a year, or when we feel that a sufficient mass of developers have gotten the message, broadcast that we're removing the default. (or changing it, if we're very confident in our plugin upgrade paths) - Some months after that, make the change. (and hopefully not be distracted by bugs in the underlying plugin code) Bump the major version again. I'm actually pretty happy with that; we think that the current situation isn't great, but it doesn't seem to be actively hurting the ecosystem. And any developers who think otherwise will now have the tools to fix it for their own apps. Eventually we can be more opinionated about it, and the plugin will be more robust, so devs shouldn't be *as* angry as if we switched it right now. Ian -Michal On Wed, Feb 5, 2014 at 10:13 AM, sebb seb...@gmail.com wrote: On 5 February 2014 14:55, David Kemp drk...@google.com wrote: My concern with any automated fix is that we have no idea what files belong to an app. The default is to just toss everything in the root. Files may be user data that is shared between apps, config files or temp files. The developer probably knows what to migrate - we don't.\ The app must tell the library what file names are involved. So unless the same API is used for files that are supposed to remain in the root, it should be possible to know what needs to move. It may still prove too difficult to implement the merge, but perhaps there is some scope for adding something to help the developers. For example, the code could check if there is a file with the same name in the old location, and log a message if so. There may be
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Joe - I appreciate your effort and your input, but I don't appreciate hostility on this list from anyone, including you. This is a public list, and I see nothing wrong with sebb's email in this thread. If you are at the point that you don't want to receive emails from sebb, then I would ask that you choose to ignore them, or to create an email filter on your end. +1 to Ian's proposal. On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser bows...@gmail.com wrote: Can you please leave this list sebb? You opinion is unwelcome! On Wed, Feb 5, 2014 at 6:05 AM, sebb seb...@gmail.com wrote: On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
+1 to Ian's proposal @purplecabbage risingj.com On Wed, Feb 5, 2014 at 1:33 PM, Andrew Grieve agri...@chromium.org wrote: Joe - I appreciate your effort and your input, but I don't appreciate hostility on this list from anyone, including you. This is a public list, and I see nothing wrong with sebb's email in this thread. If you are at the point that you don't want to receive emails from sebb, then I would ask that you choose to ignore them, or to create an email filter on your end. +1 to Ian's proposal. On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser bows...@gmail.com wrote: Can you please leave this list sebb? You opinion is unwelcome! On Wed, Feb 5, 2014 at 6:05 AM, sebb seb...@gmail.com wrote: On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
It sounds like a good plan indeed. I would encourage our users to migrate to the new locations as soon as they can. 12 months is an acceptable migration window I believe. +1 to Ian's proposal. On Wed, Feb 5, 2014 at 1:43 PM, Jesse purplecabb...@gmail.com wrote: +1 to Ian's proposal @purplecabbage risingj.com On Wed, Feb 5, 2014 at 1:33 PM, Andrew Grieve agri...@chromium.org wrote: Joe - I appreciate your effort and your input, but I don't appreciate hostility on this list from anyone, including you. This is a public list, and I see nothing wrong with sebb's email in this thread. If you are at the point that you don't want to receive emails from sebb, then I would ask that you choose to ignore them, or to create an email filter on your end. +1 to Ian's proposal. On Wed, Feb 5, 2014 at 11:01 AM, Joe Bowser bows...@gmail.com wrote: Can you please leave this list sebb? You opinion is unwelcome! On Wed, Feb 5, 2014 at 6:05 AM, sebb seb...@gmail.com wrote: On 5 February 2014 13:20, David Kemp drk...@google.com wrote: -1 to merging reads. That just sounds like a horrible thing to debug. Seems to me that developers using the plugin will have to implement something similar in order to make it easier for their users. Would it not be better to spend the time getting it right once, for the benfit of all developers, rather than hoping they each get it right? I don't know what is involved here, so this is theoretical. But I believe that compatibility should only be broken if necessary. Also that fixing a problem at source is usually a lot cheaper than requiring downstream developers/users to do so. There are lots more of them, so any extra effort they have to expend is multiplied many times. In other words, the cost-benefit should not just look at the immediate cost to the project. +1 to 'go big or go home'. Break it now. Break it obviously. But I agree that breakage - if decided on - should be obvious. On Tue, Feb 4, 2014 at 11:45 PM, Josh Soref jso...@blackberry.com wrote: Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: Plugins Release!
I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil...@gmail.com wrote: Hey All, What is the general feeling on me moving forward with a plugins release today? I could start the process this afternoon if there aren't any objections or concerns. Are there any plugins that shouldn't be released?
Re: Plugins Release!
Sounds good! On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill stevengil...@gmail.com wrote: I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil...@gmail.com wrote: Hey All, What is the general feeling on me moving forward with a plugins release today? I could start the process this afternoon if there aren't any objections or concerns. Are there any plugins that shouldn't be released?
RE: Plugins Release!
Sounds good to me! From: agri...@chromium.org Date: Tue, 4 Feb 2014 14:35:01 -0500 Subject: Re: Plugins Release! To: dev@cordova.apache.org Sounds good! On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill stevengil...@gmail.com wrote: I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil...@gmail.com wrote: Hey All, What is the general feeling on me moving forward with a plugins release today? I could start the process this afternoon if there aren't any objections or concerns. Are there any plugins that shouldn't be released?
Re: Plugins Release!
Don't do it! I think File still needs some work: https://issues.apache.org/jira/browse/CB-5974 On Tue, Feb 4, 2014 at 3:18 PM, Herm Wong kingoftheo...@hotmail.com wrote: Sounds good to me! From: agri...@chromium.org Date: Tue, 4 Feb 2014 14:35:01 -0500 Subject: Re: Plugins Release! To: dev@cordova.apache.org Sounds good! On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill stevengil...@gmail.com wrote: I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil...@gmail.com wrote: Hey All, What is the general feeling on me moving forward with a plugins release today? I could start the process this afternoon if there aren't any objections or concerns. Are there any plugins that shouldn't be released?
CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
On Tue, Feb 4, 2014 at 6:20 PM, Joe Bowser bows...@gmail.com wrote: Don't do it! I think File still needs some work: https://issues.apache.org/jira/browse/CB-5974 It's too early yet to tell whether this has become a problem, but obviously this is something that people are going to run into (and are already running into [1]) Background: Because of CB-5915 [2] (and it's android sister, CB-5916 [3]), developers who upgrade File will find that their applications crash with a log message the first time they use any of the File API. (I'd crash sooner, but File is not currently a load-on-startup sort of plugin) There was a lot of discussion about this on the list [4], and I thought that we had reached consensus, but maybe it needs one more hard look. The Problem: The log message hopefully tells them what they need to do to fix the problem, but many (most?) devs aren't going to see it; they're only going to see that their app is broken now, and come to us (hopefully) or StackOverflow (more likely) to figure out why and what to do about it. They will probably be loud, we will probably be blamed for their apps breaking (no matter how simple the fix is,) and it will probably be a bad time for everybody. It's unfortunate that we feel we have to do this; there just doesn't seem to be any other way to encourage developers to use anything but the old locations for persistent files. On Android this is the root-of-the-sdcard-even-if-its-just-a-partition-shared-by-all-apps location. On iOS, its the Documents directory, although Library makes far more sense for these sort of files. If we added a default value, the only possible default we could use is Compatibility, which means that approximately 100% of new apps will ship with that default. We *can't* use the new location as the default, because that will cause real pain for the users, not the devs. Real users will lose access to real data, and that worries me much more than a mob of angry devs with pitchforks. Options: 1. Go big or go home: Make it crash harder. I was already going to add a paragraph to the plugin.xml file to be shown on install, but we *could* make the app break on launch, rather than on the first use of File. We could force File to load on startup, or we could make Javascript alert() the dev on startup (something like please fix config.xml and then delete this line), or we could break the plugin encapsulation and make ConfigParser check for this special case. Maybe we could go even further and find a way to make it break on build. At least then apps wouldn't make it to the store broken. 2. Leave it the way it is. Brace for the angry mob with blog posts, release notes, install guides, READMEs, vigilance on StackOverfow, and hope that it's enough. 3. Put in the safe default and live with it. Accept that every single Cordova app is going to use the default and that their file storage roots will suck. By the time you've educated a developer, chances are their apps have already been released and have users with stored data. Work hard on a migration utility/plugin and make sure that it can never possibly lose data. With my Google hat[5] on, I don't mind #3 -- we've ensured that the apps created with our framework use the new defaults, since they're all new apps by definition. Wearing my Apache hat, though, I don't think it's best for Cordova in the long term. At some point, I think we should rip off the bandaid. If we don't do it now, with a major rev bump of File, then we're just postponing the hurt. There may be other options; lets try to get consensus on this before pulling the trigger. [1] https://issues.apache.org/jira/browse/CB-5899 [2] https://issues.apache.org/jira/browse/CB-5915 [3] https://issues.apache.org/jira/browse/CB-5916 [4] http://markmail.org/message/tzcljj3xgycbkx3g [5] http://www.flickr.com/photos/nooks/6858535568/ On Tue, Feb 4, 2014 at 3:18 PM, Herm Wong kingoftheo...@hotmail.com wrote: Sounds good to me! From: agri...@chromium.org Date: Tue, 4 Feb 2014 14:35:01 -0500 Subject: Re: Plugins Release! To: dev@cordova.apache.org Sounds good! On Tue, Feb 4, 2014 at 2:19 PM, Steven Gill stevengil...@gmail.com wrote: I am going to take the silence as lazy consensus. I will make sure to include the new file plugin as well. I will make sure to have a blog post of changes to review before I publish. -Steve On Mon, Feb 3, 2014 at 10:33 AM, Steven Gill stevengil...@gmail.com wrote: Hey All, What is the general feeling on me moving forward with a plugins release today? I could start the process this afternoon if there aren't any objections or concerns. Are there any plugins that shouldn't be released?
Re: CB-5974, or, Re-thinking broken-by-default (Was: Re: Plugins Release!)
Is it impossible to have reads merged from both locations, but writes go to the new location, and when a write completes in the new location, delete the old one?
Re: plugins release
No one's announced their intent to do one yet that I've seen. On Thu, Jan 16, 2014 at 2:17 PM, Herm Wong kingoftheo...@hotmail.comwrote: Are we planning on a plugin release soon? There have been quite a few commits for FirefoxOS that need to be released into the main branch.
Re: Plugins Release Tomorrow
Going to try and do this today :) On Fri, Dec 20, 2013 at 1:33 PM, Ian Clelland iclell...@chromium.orgwrote: That sounds reasonable. There isn't a huge rush on it. On Fri, Dec 20, 2013 at 10:54 AM, Andrew Grieve agri...@chromium.org wrote: Well, I didn't do this yesterday and don't want to do a Friday release, so I'll do this Monday instead. I'll skip File plugin again until someone can test WP. On Thu, Dec 19, 2013 at 1:40 AM, purplecabbage purplecabb...@gmail.com wrote: I have not. Someone needs to test the impact on windows phone before releasing this. I am away until the new year, so I cannot. Merry ho ho ! Sent from my iPhone On Dec 18, 2013, at 7:43 PM, Ian Clelland iclell...@chromium.org wrote: I think the file plugin is good -- we should be bumping the major with this one. Has anyone else had a chance to test it out? We should coordinate reverting 692f1fb with the push of file 1.0 to npm; I'm not sure how the timing on that works, but I'd like the pushed version of file-transfer to explicitly depend on the new version of file. On Wed, Dec 18, 2013 at 10:13 PM, Andrew Grieve agri...@chromium.org wrote: I'd like to do one in order to add all of the doc/index.md files to master branches. Lots of other things in there as well: agrieve@agrieve-macbookpro ~/git/cordova$ ./cordova-coho/coho repo-status -r plugins -b dev --branch2 master --no-diff | grep -v CB-5658 | grep -v 5565 ./cordova-plugin-camera/ = cordova-plugin-camera on branch dev (vs master): Commits exist. 2437c40 CB-2442 CB-2419 Use Windows.Storage.ApplicationData.current.localFolder, instead of writing to app package. ccd59e6 [BlackBerry10] Adding platform level permissions 6f4fef8 CB-5599 Android: Catch and ignore OutOfMemoryError in getRotatedBitmap() ./cordova-plugin-device/ = cordova-plugin-device on branch dev (vs master): Commits exist. 695272e CB-5504: Moving Telephony Logic out of Device ./cordova-plugin-dialogs/ cordova-plugin-dialogs on branch dev (vs master): Commits exist. b44c138 move images from css to img 96c5fa7 CB-3762 Change prompt default to empty string ./cordova-plugin-file-transfer/ = cordova-plugin-file-transfer on branch dev (vs master): Commits exist. 692f1fb Remove @1 designation from file plugin dependency until pushed to npm 647dad7 CB-5466: Update to work with filesystem URLs ./cordova-plugin-file/ === cordova-plugin-file on branch dev (vs master): Commits exist. eb28b7a CB-5403: Backwards-compatibility with file:// urls where possible a2b9073 CB-5407: Fixes for ContentFilesystem 83a867c Android: Add method for testing backwards-compatibility of filetransfer plugin 4c44780 iOS: Add method for testing backwards-compatiblity of filetransfer plugin 6f52e3b Android: Updates to allow FileTransfer to continue to work 6d0dad6 Android: Clean up unclosed file objects 0a6adf0 Merge branch android-file into dev 2550617 CB-5407: Cleanup 9f3bb54 CB-5407: Add new Android source files to plugin.xml ed4a8d7 CB-5407: Move read, write and truncate methods into modules 4859149 CB-5407: Move copy/move methods into FS modules 02e82a5 CB-5407: Move getParent into FS modules 06725c2 CB-5407: Move getmetadata methods into FS modules 85945d8 CB-5407: Move readdir methods into FS modules 919f99f CB-5407: Move remove methods into FS modules 0d0af8f CB-5407: Move getFile into FS modules 30988f7 CB-5407: Start refactoring android code: Modular filesystems, rfs, rlfsurl 225c905 CB-5407: Update android JS to use FS urls 7872b9c CB-5532 Fix cd7d925 CB-5405: Use URL formatting for Entry.toURL 95677c4 Log file path for File exceptions. 6b0ab74 Partial fix for iOS File compatibility with previous fileTransfer plugin 86f3446 Merge branch 'CB-5532' of https://github.com/sgrebnov/cordova-plugin-file into dev e0f59bd Merge branch 'CB-5531' of https://github.com/sgrebnov/cordova-plugin-file into dev ef636d9 CB-5532 WP8. Add binary data support to FileWriter f2f22ab CB-5531 WP8. File Api readAsText incorrectly handles position args 9a5278b added ubuntu support bb626c6 Merge branch 'dev' of github.com: archananaik/cordova-plugin-file into dev 093b084 CB-5118 [BlackBerry10] Add check for undefined error handler 5a1a7a2 [ubuntu] use cordova/exec/proxy 5a4d9ad CB-5406: Extend public API for dependent plugins 8d7e261 CB-5403: Bump File plugin major version 7bb3977 CB-5406: Split iOS file plugin into modules 64187ca CB-5406: Factor out filesystem providers in iOS b8c4f85 CB-5408: Add handler for filesystem:// urls b3b6a83 CB-5406: Update iOS native code to use filesystem URLs internally
Re: Plugins Release Tomorrow
Well, I didn't do this yesterday and don't want to do a Friday release, so I'll do this Monday instead. I'll skip File plugin again until someone can test WP. On Thu, Dec 19, 2013 at 1:40 AM, purplecabbage purplecabb...@gmail.comwrote: I have not. Someone needs to test the impact on windows phone before releasing this. I am away until the new year, so I cannot. Merry ho ho ! Sent from my iPhone On Dec 18, 2013, at 7:43 PM, Ian Clelland iclell...@chromium.org wrote: I think the file plugin is good -- we should be bumping the major with this one. Has anyone else had a chance to test it out? We should coordinate reverting 692f1fb with the push of file 1.0 to npm; I'm not sure how the timing on that works, but I'd like the pushed version of file-transfer to explicitly depend on the new version of file. On Wed, Dec 18, 2013 at 10:13 PM, Andrew Grieve agri...@chromium.org wrote: I'd like to do one in order to add all of the doc/index.md files to master branches. Lots of other things in there as well: agrieve@agrieve-macbookpro ~/git/cordova$ ./cordova-coho/coho repo-status -r plugins -b dev --branch2 master --no-diff | grep -v CB-5658 | grep -v 5565 ./cordova-plugin-camera/ = cordova-plugin-camera on branch dev (vs master): Commits exist. 2437c40 CB-2442 CB-2419 Use Windows.Storage.ApplicationData.current.localFolder, instead of writing to app package. ccd59e6 [BlackBerry10] Adding platform level permissions 6f4fef8 CB-5599 Android: Catch and ignore OutOfMemoryError in getRotatedBitmap() ./cordova-plugin-device/ = cordova-plugin-device on branch dev (vs master): Commits exist. 695272e CB-5504: Moving Telephony Logic out of Device ./cordova-plugin-dialogs/ cordova-plugin-dialogs on branch dev (vs master): Commits exist. b44c138 move images from css to img 96c5fa7 CB-3762 Change prompt default to empty string ./cordova-plugin-file-transfer/ = cordova-plugin-file-transfer on branch dev (vs master): Commits exist. 692f1fb Remove @1 designation from file plugin dependency until pushed to npm 647dad7 CB-5466: Update to work with filesystem URLs ./cordova-plugin-file/ === cordova-plugin-file on branch dev (vs master): Commits exist. eb28b7a CB-5403: Backwards-compatibility with file:// urls where possible a2b9073 CB-5407: Fixes for ContentFilesystem 83a867c Android: Add method for testing backwards-compatibility of filetransfer plugin 4c44780 iOS: Add method for testing backwards-compatiblity of filetransfer plugin 6f52e3b Android: Updates to allow FileTransfer to continue to work 6d0dad6 Android: Clean up unclosed file objects 0a6adf0 Merge branch android-file into dev 2550617 CB-5407: Cleanup 9f3bb54 CB-5407: Add new Android source files to plugin.xml ed4a8d7 CB-5407: Move read, write and truncate methods into modules 4859149 CB-5407: Move copy/move methods into FS modules 02e82a5 CB-5407: Move getParent into FS modules 06725c2 CB-5407: Move getmetadata methods into FS modules 85945d8 CB-5407: Move readdir methods into FS modules 919f99f CB-5407: Move remove methods into FS modules 0d0af8f CB-5407: Move getFile into FS modules 30988f7 CB-5407: Start refactoring android code: Modular filesystems, rfs, rlfsurl 225c905 CB-5407: Update android JS to use FS urls 7872b9c CB-5532 Fix cd7d925 CB-5405: Use URL formatting for Entry.toURL 95677c4 Log file path for File exceptions. 6b0ab74 Partial fix for iOS File compatibility with previous fileTransfer plugin 86f3446 Merge branch 'CB-5532' of https://github.com/sgrebnov/cordova-plugin-file into dev e0f59bd Merge branch 'CB-5531' of https://github.com/sgrebnov/cordova-plugin-file into dev ef636d9 CB-5532 WP8. Add binary data support to FileWriter f2f22ab CB-5531 WP8. File Api readAsText incorrectly handles position args 9a5278b added ubuntu support bb626c6 Merge branch 'dev' of github.com: archananaik/cordova-plugin-file into dev 093b084 CB-5118 [BlackBerry10] Add check for undefined error handler 5a1a7a2 [ubuntu] use cordova/exec/proxy 5a4d9ad CB-5406: Extend public API for dependent plugins 8d7e261 CB-5403: Bump File plugin major version 7bb3977 CB-5406: Split iOS file plugin into modules 64187ca CB-5406: Factor out filesystem providers in iOS b8c4f85 CB-5408: Add handler for filesystem:// urls b3b6a83 CB-5406: Update iOS native code to use filesystem URLs internally 1dfdf0f CB-5405: Update JS code to use URLs exclusively 43c901a CB-4816 Fix file creation outside sandbox for BB10 ab9de01 [ubuntu] change location of persistent dir 396cbeb 1. Added amazon-fireos platform 2. Change to use amazon-fireos as a platform is the user agent string contains 'cordova-amazon-fireos' ca2c4e2 CB-5188: af8d7c2 add ubuntu platform ./cordova-plugin-geolocation/ = cordova-plugin-geolocation on branch dev (vs master): Commits exist. 179993f windows8. adds missing
Re: Plugins Release Tomorrow
That sounds reasonable. There isn't a huge rush on it. On Fri, Dec 20, 2013 at 10:54 AM, Andrew Grieve agri...@chromium.orgwrote: Well, I didn't do this yesterday and don't want to do a Friday release, so I'll do this Monday instead. I'll skip File plugin again until someone can test WP. On Thu, Dec 19, 2013 at 1:40 AM, purplecabbage purplecabb...@gmail.com wrote: I have not. Someone needs to test the impact on windows phone before releasing this. I am away until the new year, so I cannot. Merry ho ho ! Sent from my iPhone On Dec 18, 2013, at 7:43 PM, Ian Clelland iclell...@chromium.org wrote: I think the file plugin is good -- we should be bumping the major with this one. Has anyone else had a chance to test it out? We should coordinate reverting 692f1fb with the push of file 1.0 to npm; I'm not sure how the timing on that works, but I'd like the pushed version of file-transfer to explicitly depend on the new version of file. On Wed, Dec 18, 2013 at 10:13 PM, Andrew Grieve agri...@chromium.org wrote: I'd like to do one in order to add all of the doc/index.md files to master branches. Lots of other things in there as well: agrieve@agrieve-macbookpro ~/git/cordova$ ./cordova-coho/coho repo-status -r plugins -b dev --branch2 master --no-diff | grep -v CB-5658 | grep -v 5565 ./cordova-plugin-camera/ = cordova-plugin-camera on branch dev (vs master): Commits exist. 2437c40 CB-2442 CB-2419 Use Windows.Storage.ApplicationData.current.localFolder, instead of writing to app package. ccd59e6 [BlackBerry10] Adding platform level permissions 6f4fef8 CB-5599 Android: Catch and ignore OutOfMemoryError in getRotatedBitmap() ./cordova-plugin-device/ = cordova-plugin-device on branch dev (vs master): Commits exist. 695272e CB-5504: Moving Telephony Logic out of Device ./cordova-plugin-dialogs/ cordova-plugin-dialogs on branch dev (vs master): Commits exist. b44c138 move images from css to img 96c5fa7 CB-3762 Change prompt default to empty string ./cordova-plugin-file-transfer/ = cordova-plugin-file-transfer on branch dev (vs master): Commits exist. 692f1fb Remove @1 designation from file plugin dependency until pushed to npm 647dad7 CB-5466: Update to work with filesystem URLs ./cordova-plugin-file/ === cordova-plugin-file on branch dev (vs master): Commits exist. eb28b7a CB-5403: Backwards-compatibility with file:// urls where possible a2b9073 CB-5407: Fixes for ContentFilesystem 83a867c Android: Add method for testing backwards-compatibility of filetransfer plugin 4c44780 iOS: Add method for testing backwards-compatiblity of filetransfer plugin 6f52e3b Android: Updates to allow FileTransfer to continue to work 6d0dad6 Android: Clean up unclosed file objects 0a6adf0 Merge branch android-file into dev 2550617 CB-5407: Cleanup 9f3bb54 CB-5407: Add new Android source files to plugin.xml ed4a8d7 CB-5407: Move read, write and truncate methods into modules 4859149 CB-5407: Move copy/move methods into FS modules 02e82a5 CB-5407: Move getParent into FS modules 06725c2 CB-5407: Move getmetadata methods into FS modules 85945d8 CB-5407: Move readdir methods into FS modules 919f99f CB-5407: Move remove methods into FS modules 0d0af8f CB-5407: Move getFile into FS modules 30988f7 CB-5407: Start refactoring android code: Modular filesystems, rfs, rlfsurl 225c905 CB-5407: Update android JS to use FS urls 7872b9c CB-5532 Fix cd7d925 CB-5405: Use URL formatting for Entry.toURL 95677c4 Log file path for File exceptions. 6b0ab74 Partial fix for iOS File compatibility with previous fileTransfer plugin 86f3446 Merge branch 'CB-5532' of https://github.com/sgrebnov/cordova-plugin-file into dev e0f59bd Merge branch 'CB-5531' of https://github.com/sgrebnov/cordova-plugin-file into dev ef636d9 CB-5532 WP8. Add binary data support to FileWriter f2f22ab CB-5531 WP8. File Api readAsText incorrectly handles position args 9a5278b added ubuntu support bb626c6 Merge branch 'dev' of github.com: archananaik/cordova-plugin-file into dev 093b084 CB-5118 [BlackBerry10] Add check for undefined error handler 5a1a7a2 [ubuntu] use cordova/exec/proxy 5a4d9ad CB-5406: Extend public API for dependent plugins 8d7e261 CB-5403: Bump File plugin major version 7bb3977 CB-5406: Split iOS file plugin into modules 64187ca CB-5406: Factor out filesystem providers in iOS b8c4f85 CB-5408: Add handler for filesystem:// urls b3b6a83 CB-5406: Update iOS native code to use filesystem URLs internally 1dfdf0f CB-5405: Update JS code to use URLs exclusively 43c901a CB-4816 Fix file creation outside sandbox for BB10 ab9de01 [ubuntu] change location of persistent dir 396cbeb 1. Added amazon-fireos platform 2. Change to use amazon-fireos as
Re: Plugins Release today
Hey Sergey, We can still add the lines. The File plugin didn't get released with this release. Feel free to share the line you want added about contacts with me and I can add it to the blog post. You are always welcomed to go edit the blog post by pulling down the site if you want to go that route instead. -Steve On Thu, Dec 5, 2013 at 12:38 AM, Sergey Grebnov (Akvelon) v-seg...@microsoft.com wrote: Congrats and thx! I have the only following concern - since release info review process goes very fast (during my night) I can't participate in it :) For example for WP8 I would love to add one line note about important fixes in Contacts api and File api. I'll figure out how we can improve this with Jesse and my US team. Thx! Sergey -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Thursday, December 5, 2013 8:44 AM To: dev@cordova.apache.org Subject: Re: Plugins Release today Thanks Steve! On Wed, Dec 4, 2013 at 11:07 PM, Andrew Grieve agri...@chromium.org wrote: Great job! Thanks indeed! On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux b...@brian.io wrote: thx Steve! On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill stevengil...@gmail.com wrote: Plugins have been released! http://cordova.apache.org/news/2013/12/04/plugins-release.html https://twitter.com/apachecordova/status/408441655222476800 device-motion and battery-status haven't been published yet due to a error I ran into with plugman publish. I have pinged Anis to take a look. They will be up asap. File also didn't get released today. It will hopefully be ready to get released next week before 3.3.0 final! Cheers, -Steve On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref jso...@blackberry.com wrote: I suspect we almost always want to test new feature against tip-of-tree (I guess thats master). For what I believe are hysterical reasons, I think it's sometimes called dev. So being able to run that but replace some of the repos with a different branch would be awesome. What if we used the convention of naming feature branches in all the applicable repos the same thing, that way we can poke CI with a single name and it would check out that branch on all the repos if it existed? - 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. -- Carlos Santana csantan...@gmail.com
RE: Plugins Release today
Thank you, Steve! It is definitely a good reserve way to proceed, but I think we should target to single post and no changes after so I'm discussing options with my colleagues to see if there is an easy way to achieve this. As for the current release let's keep it as is in this situation. Thank you! -Sergey -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, December 5, 2013 10:52 PM To: dev@cordova.apache.org Subject: Re: Plugins Release today Hey Sergey, We can still add the lines. The File plugin didn't get released with this release. Feel free to share the line you want added about contacts with me and I can add it to the blog post. You are always welcomed to go edit the blog post by pulling down the site if you want to go that route instead. -Steve On Thu, Dec 5, 2013 at 12:38 AM, Sergey Grebnov (Akvelon) v-seg...@microsoft.com wrote: Congrats and thx! I have the only following concern - since release info review process goes very fast (during my night) I can't participate in it :) For example for WP8 I would love to add one line note about important fixes in Contacts api and File api. I'll figure out how we can improve this with Jesse and my US team. Thx! Sergey -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Thursday, December 5, 2013 8:44 AM To: dev@cordova.apache.org Subject: Re: Plugins Release today Thanks Steve! On Wed, Dec 4, 2013 at 11:07 PM, Andrew Grieve agri...@chromium.org wrote: Great job! Thanks indeed! On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux b...@brian.io wrote: thx Steve! On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill stevengil...@gmail.com wrote: Plugins have been released! http://cordova.apache.org/news/2013/12/04/plugins-release.html https://twitter.com/apachecordova/status/408441655222476800 device-motion and battery-status haven't been published yet due to a error I ran into with plugman publish. I have pinged Anis to take a look. They will be up asap. File also didn't get released today. It will hopefully be ready to get released next week before 3.3.0 final! Cheers, -Steve On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref jso...@blackberry.com wrote: I suspect we almost always want to test new feature against tip-of-tree (I guess thats master). For what I believe are hysterical reasons, I think it's sometimes called dev. So being able to run that but replace some of the repos with a different branch would be awesome. What if we used the convention of naming feature branches in all the applicable repos the same thing, that way we can poke CI with a single name and it would check out that branch on all the repos if it existed? -- -- - 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. -- Carlos Santana csantan...@gmail.com
Re: Plugins Release today
You can definitely do an automated build on demand, but the interesting part is specifying exactly what to build. Currently a build is made up of a bunch of repos at one tag, and some other repos at another tag. We would need to have a well defined way to specify which tag for each repo. example: I want to build cordova-android from the 'fancy-pants' branch, because I am ready to push it to master I presumably need: cordova-android - fancy-pants branch cli,plugman,coho,mobilespec, js from master branch all plugins from master branch If we can ALWAYS say that a demand build is the same as a master build, but with one repo at a different branch that might be pretty easy... On Wed, Dec 4, 2013 at 2:44 PM, Ian Clelland iclell...@google.com wrote: On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill stevengil...@gmail.com wrote: On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland iclell...@google.com wrote: Dev becomes a staging branch, essentially; and all actual dev work happens on branches. That sounds like a more sane way to do it. The only reason I had it on dev in the first place was to be able to test with buildbot -- I'd love to have a way to run those branches through the CI server before merging them into dev/staging/master. Good point. Maybe we standardize a third branch (ducks for cover) that the CI server also tests and can be used for breaking dev work. This way dev is used for staging and only has code that can be released. I'm afraid that this just adds more complexity to plugins though and I am not a fan of adding more complexity. I was thinking that it would be cool to be able to force a buildbot build of a specific branch (though maybe a set of branches would be required) -- it wouldn't have to happen with every commit, but you could say I'm ready to merge my feature into dev, let's get buildbot to run all of the tests on that branch first, to see if the merge will break anything. That would avoid the need for a third special branch, but would let anybody with access to buildbot (which we hope is everybody, soon) the ability to test a branch before merging. I don't know if it's possible to get buildbot to do that or not; I'll defer to David on that subject :) Ian Ian Still confusing at times. It will be nice once we can get away from this dev-master setup we have. I'm sure many of us have pushed code to dev that isn't in a sate to be released. Maybe this point/process should get added to our wiki? Not sure where the best place for it would be. On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland iclell...@google.com wrote: Hey Steven, File is close to being ready, but I haven't merged in my Android code yet, and I want to add some more tests, given how critical the plugin is. I'm not comfortable with it going to master yet. If you want, I can pull it out of dev and put it on another branch. (There have been some other commits, so we could also create a new branch without those commits, and merge *that* into master instead) Let me know how you want to handle it, I'll help out any way I can. Ian On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill stevengil...@gmail.com wrote: Any plugin issues I should know about before releasing today? Last I heard file and file-transfer dev branches aren't ready to be merged into master. Has this changed? Ian? Plugin issues that are still being reviewed/worked on: https://issues.apache.org/jira/browse/CB-5525 https://issues.apache.org/jira/browse/CB-5531 https://issues.apache.org/jira/browse/CB-5532 https://issues.apache.org/jira/browse/CB-5430 https://issues.apache.org/jira/browse/CB-5504 https://issues.apache.org/jira/browse/CB-5505 I can wait until later in the day to release if some of these are getting resolve today. I know Jesse is looking at the windows ones. We can also just do another plugin release next week (or post holidays) once some of these land.
Re: Plugins Release today
On Wed, Dec 4, 2013 at 2:54 PM, David Kemp drk...@google.com wrote: You can definitely do an automated build on demand, but the interesting part is specifying exactly what to build. Currently a build is made up of a bunch of repos at one tag, and some other repos at another tag. We would need to have a well defined way to specify which tag for each repo. example: I want to build cordova-android from the 'fancy-pants' branch, because I am ready to push it to master I presumably need: cordova-android - fancy-pants branch cli,plugman,coho,mobilespec, js from master branch all plugins from master branch If we can ALWAYS say that a demand build is the same as a master build, but with one repo at a different branch that might be pretty easy... +1 to this. I suspect we almost always want to test new feature against tip-of-tree (I guess thats master). So being able to run that but replace some of the repos with a different branch would be awesome. What if we used the convention of naming feature branches in all the applicable repos the same thing, that way we can poke CI with a single name and it would check out that branch on all the repos if it existed? On Wed, Dec 4, 2013 at 2:44 PM, Ian Clelland iclell...@google.com wrote: On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill stevengil...@gmail.com wrote: On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland iclell...@google.com wrote: Dev becomes a staging branch, essentially; and all actual dev work happens on branches. That sounds like a more sane way to do it. The only reason I had it on dev in the first place was to be able to test with buildbot -- I'd love to have a way to run those branches through the CI server before merging them into dev/staging/master. Good point. Maybe we standardize a third branch (ducks for cover) that the CI server also tests and can be used for breaking dev work. This way dev is used for staging and only has code that can be released. I'm afraid that this just adds more complexity to plugins though and I am not a fan of adding more complexity. I was thinking that it would be cool to be able to force a buildbot build of a specific branch (though maybe a set of branches would be required) -- it wouldn't have to happen with every commit, but you could say I'm ready to merge my feature into dev, let's get buildbot to run all of the tests on that branch first, to see if the merge will break anything. That would avoid the need for a third special branch, but would let anybody with access to buildbot (which we hope is everybody, soon) the ability to test a branch before merging. I don't know if it's possible to get buildbot to do that or not; I'll defer to David on that subject :) Ian Ian Still confusing at times. It will be nice once we can get away from this dev-master setup we have. I'm sure many of us have pushed code to dev that isn't in a sate to be released. Maybe this point/process should get added to our wiki? Not sure where the best place for it would be. On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland iclell...@google.com wrote: Hey Steven, File is close to being ready, but I haven't merged in my Android code yet, and I want to add some more tests, given how critical the plugin is. I'm not comfortable with it going to master yet. If you want, I can pull it out of dev and put it on another branch. (There have been some other commits, so we could also create a new branch without those commits, and merge *that* into master instead) Let me know how you want to handle it, I'll help out any way I can. Ian On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill stevengil...@gmail.com wrote: Any plugin issues I should know about before releasing today? Last I heard file and file-transfer dev branches aren't ready to be merged into master. Has this changed? Ian? Plugin issues that are still being reviewed/worked on: https://issues.apache.org/jira/browse/CB-5525 https://issues.apache.org/jira/browse/CB-5531 https://issues.apache.org/jira/browse/CB-5532 https://issues.apache.org/jira/browse/CB-5430 https://issues.apache.org/jira/browse/CB-5504 https://issues.apache.org/jira/browse/CB-5505 I can wait until later in the day to release if some of these are getting resolve today. I know Jesse is looking at the windows ones. We can also just do another plugin release next week (or post holidays) once some of these land.
Re: Plugins Release today
Plugins have been released! http://cordova.apache.org/news/2013/12/04/plugins-release.html https://twitter.com/apachecordova/status/408441655222476800 device-motion and battery-status haven't been published yet due to a error I ran into with plugman publish. I have pinged Anis to take a look. They will be up asap. File also didn't get released today. It will hopefully be ready to get released next week before 3.3.0 final! Cheers, -Steve On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref jso...@blackberry.com wrote: I suspect we almost always want to test new feature against tip-of-tree (I guess thats master). For what I believe are hysterical reasons, I think it's sometimes called dev. So being able to run that but replace some of the repos with a different branch would be awesome. What if we used the convention of naming feature branches in all the applicable repos the same thing, that way we can poke CI with a single name and it would check out that branch on all the repos if it existed? - 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: Plugins Release today
thx Steve! On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill stevengil...@gmail.com wrote: Plugins have been released! http://cordova.apache.org/news/2013/12/04/plugins-release.html https://twitter.com/apachecordova/status/408441655222476800 device-motion and battery-status haven't been published yet due to a error I ran into with plugman publish. I have pinged Anis to take a look. They will be up asap. File also didn't get released today. It will hopefully be ready to get released next week before 3.3.0 final! Cheers, -Steve On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref jso...@blackberry.com wrote: I suspect we almost always want to test new feature against tip-of-tree (I guess thats master). For what I believe are hysterical reasons, I think it's sometimes called dev. So being able to run that but replace some of the repos with a different branch would be awesome. What if we used the convention of naming feature branches in all the applicable repos the same thing, that way we can poke CI with a single name and it would check out that branch on all the repos if it existed? - 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: Plugins Release today
Great job! Thanks indeed! On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux b...@brian.io wrote: thx Steve! On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill stevengil...@gmail.com wrote: Plugins have been released! http://cordova.apache.org/news/2013/12/04/plugins-release.html https://twitter.com/apachecordova/status/408441655222476800 device-motion and battery-status haven't been published yet due to a error I ran into with plugman publish. I have pinged Anis to take a look. They will be up asap. File also didn't get released today. It will hopefully be ready to get released next week before 3.3.0 final! Cheers, -Steve On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref jso...@blackberry.com wrote: I suspect we almost always want to test new feature against tip-of-tree (I guess thats master). For what I believe are hysterical reasons, I think it's sometimes called dev. So being able to run that but replace some of the repos with a different branch would be awesome. What if we used the convention of naming feature branches in all the applicable repos the same thing, that way we can poke CI with a single name and it would check out that branch on all the repos if it existed? - 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: Plugins Release today
Hey Steven, File is close to being ready, but I haven't merged in my Android code yet, and I want to add some more tests, given how critical the plugin is. I'm not comfortable with it going to master yet. If you want, I can pull it out of dev and put it on another branch. (There have been some other commits, so we could also create a new branch without those commits, and merge *that* into master instead) Let me know how you want to handle it, I'll help out any way I can. Ian On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill stevengil...@gmail.com wrote: Any plugin issues I should know about before releasing today? Last I heard file and file-transfer dev branches aren't ready to be merged into master. Has this changed? Ian? Plugin issues that are still being reviewed/worked on: https://issues.apache.org/jira/browse/CB-5525 https://issues.apache.org/jira/browse/CB-5531 https://issues.apache.org/jira/browse/CB-5532 https://issues.apache.org/jira/browse/CB-5430 https://issues.apache.org/jira/browse/CB-5504 https://issues.apache.org/jira/browse/CB-5505 I can wait until later in the day to release if some of these are getting resolve today. I know Jesse is looking at the windows ones. We can also just do another plugin release next week (or post holidays) once some of these land.
Re: Plugins Release today
Thanks for filling me in on the state! Is it just File that isn't ready? File-transfer is good? I don't think it is worth it to rip out the code from dev, especially if it is almost ready. I will hold off releasing file with this plugins release. We can aim to get a new version of file out next week after it has been tested (especially with plugins that depend on it). Of course, if you strongly feel some of those other commits on file should get out asap, then lets move forward with ripping out so it can be released. In the future we should all try to work off branches and push code onto dev that is ready to be pushed to master. We should use dev as master since our master branch is just for releasing. Still confusing at times. It will be nice once we can get away from this dev-master setup we have. I'm sure many of us have pushed code to dev that isn't in a sate to be released. Maybe this point/process should get added to our wiki? Not sure where the best place for it would be. On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland iclell...@google.com wrote: Hey Steven, File is close to being ready, but I haven't merged in my Android code yet, and I want to add some more tests, given how critical the plugin is. I'm not comfortable with it going to master yet. If you want, I can pull it out of dev and put it on another branch. (There have been some other commits, so we could also create a new branch without those commits, and merge *that* into master instead) Let me know how you want to handle it, I'll help out any way I can. Ian On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill stevengil...@gmail.com wrote: Any plugin issues I should know about before releasing today? Last I heard file and file-transfer dev branches aren't ready to be merged into master. Has this changed? Ian? Plugin issues that are still being reviewed/worked on: https://issues.apache.org/jira/browse/CB-5525 https://issues.apache.org/jira/browse/CB-5531 https://issues.apache.org/jira/browse/CB-5532 https://issues.apache.org/jira/browse/CB-5430 https://issues.apache.org/jira/browse/CB-5504 https://issues.apache.org/jira/browse/CB-5505 I can wait until later in the day to release if some of these are getting resolve today. I know Jesse is looking at the windows ones. We can also just do another plugin release next week (or post holidays) once some of these land.
Re: Plugins Release
Plugins have been released for this week. http://cordova.apache.org/news/2013/10/10/plugins-release.html On Wed, Oct 9, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org wrote: Btw - sounds good about plugin release! No need to add the labs plugins (as you said, they are already there), but it would be good to mention them in your blog post (just the published ones: keyboard, websql, statusbar). On Wed, Oct 9, 2013 at 4:32 PM, Andrew Grieve agri...@chromium.org wrote: An alternative to new repos for all of them is to put them in their platform repos. So far none of them have multiple platforms. I'd like to wait a while before creating too many more plugin repositories, just until the number of plugins levels out. On Wed, Oct 9, 2013 at 3:32 PM, Steven Gill stevengil...@gmail.com wrote: So plugins that are on cordova-labs will not be included in my release this week. It seems like people have been publishing the cordova-labs plugins independently so far from the (bi)-weekly plugins release. Plugins in cordova-labs include: keyboard (published to registry) websql (published to registry) statusbar (published to registry) file-extras android storage I propose that these plugins (especially the top 3) get moved into repos of their own and join the plugin release train starting with the next release. This way we prevent the plugins branch from becoming another case of https://github.com/phonegap/phonegap-plugins Thoughts? -Steve On Wed, Oct 9, 2013 at 11:24 AM, Steven Gill stevengil...@gmail.com wrote: I am about to initiate the process for doing this release today. This will include generating release notes + updating versions for the plugins that have changes since the last release. I will then publish them to the registry and whip up a blog post. I heard we have more plugins on cordova-labs that could benefit from being included in this plugins release process. I would love for people to let me know on this thread what plugins I should be looking at other than our core ones. On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill stevengil...@gmail.com wrote: https://issues.apache.org/jira/browse/CB-5010 On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill stevengil...@gmail.com wrote: If we want to do CLI/Plugman, we definitely will need to do more testing and fix some things (like FFOS). I think we also need to make sure that some of the changes that went into cordova-3.1.x branches also ended up in the refactored master branches. I will plan on doing the plugins release tomorrow/Wednesday. Steve On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve agri...@chromium.org wrote: I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
Just as a side note: this release should also fix file-transfer on WP7 WP8 = https://issues.apache.org/jira/browse/CB-4668 https://issues.apache.org/jira/browse/CB-4717 Best, Wolfgang Am 2013-10-11 01:25, schrieb Steven Gill: Plugins have been released for this week. http://cordova.apache.org/news/2013/10/10/plugins-release.html On Wed, Oct 9, 2013 at 1:34 PM, Andrew Grieve agri...@chromium.org wrote: Btw - sounds good about plugin release! No need to add the labs plugins (as you said, they are already there), but it would be good to mention them in your blog post (just the published ones: keyboard, websql, statusbar). On Wed, Oct 9, 2013 at 4:32 PM, Andrew Grieve agri...@chromium.org wrote: An alternative to new repos for all of them is to put them in their platform repos. So far none of them have multiple platforms. I'd like to wait a while before creating too many more plugin repositories, just until the number of plugins levels out. On Wed, Oct 9, 2013 at 3:32 PM, Steven Gill stevengil...@gmail.com wrote: So plugins that are on cordova-labs will not be included in my release this week. It seems like people have been publishing the cordova-labs plugins independently so far from the (bi)-weekly plugins release. Plugins in cordova-labs include: keyboard (published to registry) websql (published to registry) statusbar (published to registry) file-extras android storage I propose that these plugins (especially the top 3) get moved into repos of their own and join the plugin release train starting with the next release. This way we prevent the plugins branch from becoming another case of https://github.com/phonegap/phonegap-plugins Thoughts? -Steve On Wed, Oct 9, 2013 at 11:24 AM, Steven Gill stevengil...@gmail.com wrote: I am about to initiate the process for doing this release today. This will include generating release notes + updating versions for the plugins that have changes since the last release. I will then publish them to the registry and whip up a blog post. I heard we have more plugins on cordova-labs that could benefit from being included in this plugins release process. I would love for people to let me know on this thread what plugins I should be looking at other than our core ones. On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill stevengil...@gmail.com wrote: https://issues.apache.org/jira/browse/CB-5010 On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill stevengil...@gmail.com wrote: If we want to do CLI/Plugman, we definitely will need to do more testing and fix some things (like FFOS). I think we also need to make sure that some of the changes that went into cordova-3.1.x branches also ended up in the refactored master branches. I will plan on doing the plugins release tomorrow/Wednesday. Steve On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve agri...@chromium.org wrote: I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve -- GOFG - Get On Fat Guy http://www.gofg.at/ - powered by Cordova
Re: Plugins Release
So plugins that are on cordova-labs will not be included in my release this week. It seems like people have been publishing the cordova-labs plugins independently so far from the (bi)-weekly plugins release. Plugins in cordova-labs include: keyboard (published to registry) websql (published to registry) statusbar (published to registry) file-extras android storage I propose that these plugins (especially the top 3) get moved into repos of their own and join the plugin release train starting with the next release. This way we prevent the plugins branch from becoming another case of https://github.com/phonegap/phonegap-plugins Thoughts? -Steve On Wed, Oct 9, 2013 at 11:24 AM, Steven Gill stevengil...@gmail.com wrote: I am about to initiate the process for doing this release today. This will include generating release notes + updating versions for the plugins that have changes since the last release. I will then publish them to the registry and whip up a blog post. I heard we have more plugins on cordova-labs that could benefit from being included in this plugins release process. I would love for people to let me know on this thread what plugins I should be looking at other than our core ones. On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill stevengil...@gmail.comwrote: https://issues.apache.org/jira/browse/CB-5010 On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill stevengil...@gmail.comwrote: If we want to do CLI/Plugman, we definitely will need to do more testing and fix some things (like FFOS). I think we also need to make sure that some of the changes that went into cordova-3.1.x branches also ended up in the refactored master branches. I will plan on doing the plugins release tomorrow/Wednesday. Steve On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve agri...@chromium.orgwrote: I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
An alternative to new repos for all of them is to put them in their platform repos. So far none of them have multiple platforms. I'd like to wait a while before creating too many more plugin repositories, just until the number of plugins levels out. On Wed, Oct 9, 2013 at 3:32 PM, Steven Gill stevengil...@gmail.com wrote: So plugins that are on cordova-labs will not be included in my release this week. It seems like people have been publishing the cordova-labs plugins independently so far from the (bi)-weekly plugins release. Plugins in cordova-labs include: keyboard (published to registry) websql (published to registry) statusbar (published to registry) file-extras android storage I propose that these plugins (especially the top 3) get moved into repos of their own and join the plugin release train starting with the next release. This way we prevent the plugins branch from becoming another case of https://github.com/phonegap/phonegap-plugins Thoughts? -Steve On Wed, Oct 9, 2013 at 11:24 AM, Steven Gill stevengil...@gmail.com wrote: I am about to initiate the process for doing this release today. This will include generating release notes + updating versions for the plugins that have changes since the last release. I will then publish them to the registry and whip up a blog post. I heard we have more plugins on cordova-labs that could benefit from being included in this plugins release process. I would love for people to let me know on this thread what plugins I should be looking at other than our core ones. On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill stevengil...@gmail.com wrote: https://issues.apache.org/jira/browse/CB-5010 On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill stevengil...@gmail.com wrote: If we want to do CLI/Plugman, we definitely will need to do more testing and fix some things (like FFOS). I think we also need to make sure that some of the changes that went into cordova-3.1.x branches also ended up in the refactored master branches. I will plan on doing the plugins release tomorrow/Wednesday. Steve On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve agri...@chromium.org wrote: I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
Btw - sounds good about plugin release! No need to add the labs plugins (as you said, they are already there), but it would be good to mention them in your blog post (just the published ones: keyboard, websql, statusbar). On Wed, Oct 9, 2013 at 4:32 PM, Andrew Grieve agri...@chromium.org wrote: An alternative to new repos for all of them is to put them in their platform repos. So far none of them have multiple platforms. I'd like to wait a while before creating too many more plugin repositories, just until the number of plugins levels out. On Wed, Oct 9, 2013 at 3:32 PM, Steven Gill stevengil...@gmail.comwrote: So plugins that are on cordova-labs will not be included in my release this week. It seems like people have been publishing the cordova-labs plugins independently so far from the (bi)-weekly plugins release. Plugins in cordova-labs include: keyboard (published to registry) websql (published to registry) statusbar (published to registry) file-extras android storage I propose that these plugins (especially the top 3) get moved into repos of their own and join the plugin release train starting with the next release. This way we prevent the plugins branch from becoming another case of https://github.com/phonegap/phonegap-plugins Thoughts? -Steve On Wed, Oct 9, 2013 at 11:24 AM, Steven Gill stevengil...@gmail.com wrote: I am about to initiate the process for doing this release today. This will include generating release notes + updating versions for the plugins that have changes since the last release. I will then publish them to the registry and whip up a blog post. I heard we have more plugins on cordova-labs that could benefit from being included in this plugins release process. I would love for people to let me know on this thread what plugins I should be looking at other than our core ones. On Mon, Oct 7, 2013 at 12:37 PM, Steven Gill stevengil...@gmail.com wrote: https://issues.apache.org/jira/browse/CB-5010 On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill stevengil...@gmail.com wrote: If we want to do CLI/Plugman, we definitely will need to do more testing and fix some things (like FFOS). I think we also need to make sure that some of the changes that went into cordova-3.1.x branches also ended up in the refactored master branches. I will plan on doing the plugins release tomorrow/Wednesday. Steve On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve agri...@chromium.org wrote: I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.orgwrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.comwrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.orgwrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
If we want to do CLI/Plugman, we definitely will need to do more testing and fix some things (like FFOS). I think we also need to make sure that some of the changes that went into cordova-3.1.x branches also ended up in the refactored master branches. I will plan on doing the plugins release tomorrow/Wednesday. Steve On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve agri...@chromium.org wrote: I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release
https://issues.apache.org/jira/browse/CB-5010 On Mon, Oct 7, 2013 at 3:24 PM, Steven Gill stevengil...@gmail.com wrote: If we want to do CLI/Plugman, we definitely will need to do more testing and fix some things (like FFOS). I think we also need to make sure that some of the changes that went into cordova-3.1.x branches also ended up in the refactored master branches. I will plan on doing the plugins release tomorrow/Wednesday. Steve On Mon, Oct 7, 2013 at 3:16 PM, Andrew Grieve agri...@chromium.orgwrote: I remember someone said the refactoring broke ffos. Not sure if that's fixed yet? Other than that, sounds great to release both this week. Would be good to do them together so as to have a shared blog post. On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: Er, I didn't actually say: for the tools, not yet, maybe later this week. Braden On Mon, Oct 7, 2013 at 3:04 PM, Braden Shepherdson bra...@chromium.org wrote: I'll want to have a hand in the next release of the tools, because of the refactoring. Braden On Mon, Oct 7, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Last week as we were finishing off the release, I remember their was some interest in doing another plugins release this week. I know windows 8 file transfer needs to be updated and Shaz has some iOS releated plugin changes that could be updated as well. Any resistance to me kicking this off and aiming to get out a plugins release tomorrow/wed? We can also do CLI/Plugman releases on a weekly basis. If anyone has a reason to update one of these, let me know and we can kick up a separate thread. I feel like I got a pretty solid understanding of our various release processes over that last two weeks. -Steve
Re: Plugins Release blog post
Can we serve the html doc somewhere? I'd rather not read a diff on html. On 26 September 2013 18:08, Steven Gill stevengil...@gmail.com wrote: Looks like I forgot to click publish on the review page. I also found a bunch of spelling mistakes I made in my rush to create this. I just fixed them and uploaded a new diff. The review site should be available for all now to leave feedback. On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill stevengil...@gmail.com wrote: Today we are doing a big plugin release in preperation for Apache Cordova 3.1.0 which is scheduled to come out next week. The main change for this release is removing core from all of the plugin ID fields. This was done to make installing plugins easier in 3.1.0. We are switching over to using plugin IDs and ourplugin registery http://plugins.cordova.io/ for plugin installation instead of directly installing from the plugin git urls. These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade your current plugins if you can’t wait for 3.1.0 next week. Keep in mind that after you install these update plugins, if you decide to remove these plugins from your project, you will have to reference the new IDs instead of the old ones that our docs show. Ex: ‘cordova rm org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’. *Other Notable Changes:* - Firefox OS support for Vibration and Device Plugin - Windows 8 support for multiple plugins - Fixed warnings that arose with XCode 5 - CB-4847 iOS 7 microphone access requires user permission (media plugin) - CB-4799 Fix incorrect JS references within native code for iOS Andrid (media plugin) - CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen plugin) - CB-4593 Added vibration support for BB10 (vibration plugin) You can check out the individual release notes in each of the plugin repos for more details. On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill stevengil...@gmail.com wrote: I have no idea how this review stuff works. I will post the blog here On Sep 26, 2013 4:59 PM, Tim Kim timki...@gmail.com wrote: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. Ya, same here On 26 September 2013 16:37, Shazron shaz...@gmail.com wrote: Does everyone have access to this? I get: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill stevengil...@gmail.com wrote: Can you guys review it at https://reviews.apache.org/r/14356/ I don't think post-review was working properly for me... -- Timothy Kim -- Timothy Kim
Re: Plugins Release blog post
best to review the .md file instead. I don't think there's a good way to host it somewhere, other than for you to download and apply the patch, and run rake serve yourself. On Fri, Sep 27, 2013 at 7:49 PM, Tim Kim timki...@gmail.com wrote: Can we serve the html doc somewhere? I'd rather not read a diff on html. On 26 September 2013 18:08, Steven Gill stevengil...@gmail.com wrote: Looks like I forgot to click publish on the review page. I also found a bunch of spelling mistakes I made in my rush to create this. I just fixed them and uploaded a new diff. The review site should be available for all now to leave feedback. On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill stevengil...@gmail.com wrote: Today we are doing a big plugin release in preperation for Apache Cordova 3.1.0 which is scheduled to come out next week. The main change for this release is removing core from all of the plugin ID fields. This was done to make installing plugins easier in 3.1.0. We are switching over to using plugin IDs and ourplugin registery http://plugins.cordova.io/ for plugin installation instead of directly installing from the plugin git urls. These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade your current plugins if you can’t wait for 3.1.0 next week. Keep in mind that after you install these update plugins, if you decide to remove these plugins from your project, you will have to reference the new IDs instead of the old ones that our docs show. Ex: ‘cordova rm org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’. *Other Notable Changes:* - Firefox OS support for Vibration and Device Plugin - Windows 8 support for multiple plugins - Fixed warnings that arose with XCode 5 - CB-4847 iOS 7 microphone access requires user permission (media plugin) - CB-4799 Fix incorrect JS references within native code for iOS Andrid (media plugin) - CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen plugin) - CB-4593 Added vibration support for BB10 (vibration plugin) You can check out the individual release notes in each of the plugin repos for more details. On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill stevengil...@gmail.com wrote: I have no idea how this review stuff works. I will post the blog here On Sep 26, 2013 4:59 PM, Tim Kim timki...@gmail.com wrote: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. Ya, same here On 26 September 2013 16:37, Shazron shaz...@gmail.com wrote: Does everyone have access to this? I get: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill stevengil...@gmail.com wrote: Can you guys review it at https://reviews.apache.org/r/14356/ I don't think post-review was working properly for me... -- Timothy Kim -- Timothy Kim
Re: Plugins Release blog post
Does everyone have access to this? I get: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill stevengil...@gmail.com wrote: Can you guys review it at https://reviews.apache.org/r/14356/ I don't think post-review was working properly for me...
Re: Plugins Release blog post
You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. Ya, same here On 26 September 2013 16:37, Shazron shaz...@gmail.com wrote: Does everyone have access to this? I get: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill stevengil...@gmail.com wrote: Can you guys review it at https://reviews.apache.org/r/14356/ I don't think post-review was working properly for me... -- Timothy Kim
Re: Plugins Release blog post
I have no idea how this review stuff works. I will post the blog here On Sep 26, 2013 4:59 PM, Tim Kim timki...@gmail.com wrote: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. Ya, same here On 26 September 2013 16:37, Shazron shaz...@gmail.com wrote: Does everyone have access to this? I get: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill stevengil...@gmail.com wrote: Can you guys review it at https://reviews.apache.org/r/14356/ I don't think post-review was working properly for me... -- Timothy Kim
Re: Plugins Release blog post
Today we are doing a big plugin release in preperation for Apache Cordova 3.1.0 which is scheduled to come out next week. The main change for this release is removing core from all of the plugin ID fields. This was done to make installing plugins easier in 3.1.0. We are switching over to using plugin IDs and ourplugin registeryhttp://plugins.cordova.io/ for plugin installation instead of directly installing from the plugin git urls. These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade your current plugins if you can’t wait for 3.1.0 next week. Keep in mind that after you install these update plugins, if you decide to remove these plugins from your project, you will have to reference the new IDs instead of the old ones that our docs show. Ex: ‘cordova rm org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’. *Other Notable Changes:* - Firefox OS support for Vibration and Device Plugin - Windows 8 support for multiple plugins - Fixed warnings that arose with XCode 5 - CB-4847 iOS 7 microphone access requires user permission (media plugin) - CB-4799 Fix incorrect JS references within native code for iOS Andrid (media plugin) - CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen plugin) - CB-4593 Added vibration support for BB10 (vibration plugin) You can check out the individual release notes in each of the plugin repos for more details. On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill stevengil...@gmail.com wrote: I have no idea how this review stuff works. I will post the blog here On Sep 26, 2013 4:59 PM, Tim Kim timki...@gmail.com wrote: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. Ya, same here On 26 September 2013 16:37, Shazron shaz...@gmail.com wrote: Does everyone have access to this? I get: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill stevengil...@gmail.com wrote: Can you guys review it at https://reviews.apache.org/r/14356/ I don't think post-review was working properly for me... -- Timothy Kim
Re: Plugins Release blog post
Looks like I forgot to click publish on the review page. I also found a bunch of spelling mistakes I made in my rush to create this. I just fixed them and uploaded a new diff. The review site should be available for all now to leave feedback. On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill stevengil...@gmail.com wrote: Today we are doing a big plugin release in preperation for Apache Cordova 3.1.0 which is scheduled to come out next week. The main change for this release is removing core from all of the plugin ID fields. This was done to make installing plugins easier in 3.1.0. We are switching over to using plugin IDs and ourplugin registeryhttp://plugins.cordova.io/ for plugin installation instead of directly installing from the plugin git urls. These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade your current plugins if you can’t wait for 3.1.0 next week. Keep in mind that after you install these update plugins, if you decide to remove these plugins from your project, you will have to reference the new IDs instead of the old ones that our docs show. Ex: ‘cordova rm org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’. *Other Notable Changes:* - Firefox OS support for Vibration and Device Plugin - Windows 8 support for multiple plugins - Fixed warnings that arose with XCode 5 - CB-4847 iOS 7 microphone access requires user permission (media plugin) - CB-4799 Fix incorrect JS references within native code for iOS Andrid (media plugin) - CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen plugin) - CB-4593 Added vibration support for BB10 (vibration plugin) You can check out the individual release notes in each of the plugin repos for more details. On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill stevengil...@gmail.comwrote: I have no idea how this review stuff works. I will post the blog here On Sep 26, 2013 4:59 PM, Tim Kim timki...@gmail.com wrote: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. Ya, same here On 26 September 2013 16:37, Shazron shaz...@gmail.com wrote: Does everyone have access to this? I get: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill stevengil...@gmail.com wrote: Can you guys review it at https://reviews.apache.org/r/14356/ I don't think post-review was working properly for me... -- Timothy Kim
