[GitHub] cordova-plugin-geolocation pull request: iOS: Clearing all Watches...
Github user Pushkar13008 commented on the pull request: https://github.com/apache/cordova-plugin-geolocation/pull/25#issuecomment-58625893 Hi, I use cordova 3.6 and last version of geolocation. I have the same issue on Android. When the watch is cleared, the symbol stays visible. Is it possible to fix this ? Thanks. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-coho pull request: [CB-7744] Add support for git-depth fla...
Github user sgrebnov commented on the pull request: https://github.com/apache/cordova-coho/pull/52#issuecomment-58634089 Does anyone know why this PR was closed w/o any comment? I personally think that this option is very valuable, for example to significantly speed up Medic which uses coho to check out platforms and plugins. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Change default path of .cordova folder
Hello guys, I want to use cordova in a multi-user environment. I have noticed that at the first use, cordova needs to download some stuff, and write them to a .cordova folder in my HOME folder. I would like to modify this process in order to have a single folder for all my users. The idea is to have all the stuff cordova needs downloaded once and at a single place. Is this possible to change the path where the .cordova folder is created ? Thanks in advance Dam
Re: Change default path of .cordova folder
Hi Dam, The code for that is here: https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/util.js#L31 So, looks like if you set your HOME / USERPROFILE variable to somewhere else that might do it. You can also try and manage your downloads separately and do things via: cordova platform add /path/to/cordova-android cordova plugin add a.b.c --searchpath=/where/my/plugins/live Even better would be if there was a CORDOVA_HOME variable... Which I'm sure we'd be fine to add given a pull request :) On Fri, Oct 10, 2014 at 3:53 AM, Damien Urruty damien.urr...@gmail.com wrote: Hello guys, I want to use cordova in a multi-user environment. I have noticed that at the first use, cordova needs to download some stuff, and write them to a .cordova folder in my HOME folder. I would like to modify this process in order to have a single folder for all my users. The idea is to have all the stuff cordova needs downloaded once and at a single place. Is this possible to change the path where the .cordova folder is created ? Thanks in advance Dam
[GitHub] cordova-coho pull request: [CB-7744] Add support for git-depth fla...
Github user agrieve commented on the pull request: https://github.com/apache/cordova-coho/pull/52#issuecomment-58642817 I don't see any commit logs that tell it close it, and I don't see it merged either. Change LGTM as well. Maybe just pull it in now even though it's closed? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: whitelist as a plugin
I'm still thinking in the old CadVer world here -- yes, it is a breaking change, and would absolutely require a major version change. 3.7.0 is certainly not a possible version number for it. I suppose the issue of master vs. 4.0.x in my head was whether the feature branch should be rooted on the branch named 4.0.x, and so depend on pluggable-webviews, or rooted on where master is today, and so be eligible for landing before the webview breakout. Of course, I'd really love both for pluggable webviews to ship, and to not have to do the whitelist work twice, so I'm happy with basing it on the 4.0.x branch. On Thu, Oct 9, 2014 at 2:28 PM, Andrew Grieve agri...@chromium.org wrote: It's technically a breaking change, so agree 4.0.x makes sense. On Thu, Oct 9, 2014 at 12:09 PM, Joe Bowser bows...@gmail.com wrote: This should land in 4.0.x On Oct 9, 2014 7:38 AM, Ian Clelland iclell...@chromium.org wrote: I'm running into more and more problems caused by the whitelist (today, it's because of the dual use of the internal whitelist for should be able to navigate to URL and should be able to XHR from URL) I'm going to start to pull it out, on a topic branch based off of Android 4.0.x right now. I'll create a JIRA issue to track the work. Is 4.0.x the best place for this to land, or is there any support for putting it on master as well, for an eventual 3.7 release? On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote: +1 to remove it for all the above reasons (and WKWebView in iOS 8) Those interested in this security blanket for checkmark ✓ purposes can install the plugin, and perhaps maintain it as well. On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote: Or remove it altogether and let the evolution of that code be maintained by those interested in the narrative it provides? :) On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org wrote: Sounds like we both agree that it doesn't work and adds a false sense of security (to those that do opt into it) :P. Maybe what we should do is redesign the whitelist to do something more useful. e.g. A whitelist that says what URLs you can navigate to is useful and easy to implement. Let's just drop the trying to stop network requests aspect of it? On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com javascript:; wrote: I'm in agreement with Andrew on this one. If we can get CSP working, that's a far better solution than our Whitelist, which was done because it was needed at the time for the enterprise use case that IBM had. I don't think we're ever going to stop are users from doing dumb things like including thirdpartyadnetworkthatdoesnoteusehttps.js in their apps any time soon, but they'll have to jump through more hoops to do dumb things, and making dumb things harder is a good thing. On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io javascript:; wrote: Heh. Why do we always seem to be at the opposite end of considerations? (Not a bad thing anyhow. ;) So making whitelist a plugin would most certainly isolate the code which would help us better understand: 1.) where the surface for bugs are (we seem to miss/find new security holes each quarter…) 2.) if people actually use it I'm more interested in #2. I suspect the only people whom do use it are security researchers disproving the whitelist veracity. I feel this API was a mistake, is misleading, and ultimately leads to poor web security practices wrt 3rd part scripts. I'd like the evidence to remove it completely and making it a plugin would do that. (And still allow for its existence to those whom want to contribute to a marketing based api.) On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve agri...@chromium.org javascript:; wrote: I don't think moving the whitelist to a plugin would aid in its understanding. Right now the whitelist is used for two things: 1. Whether to allow network requests through (although this is broken for audio/video on iOS, and broken for them + websockets on Android 2. Whether to allow top frame navigations (e.g. clicking a link to http:// * opens in system browser vs. webview) #1 doesn't work very well due to technical limitations. #2 is actually the more import one security-wise I think, and I don't think should be relegated to a plugin. I'm hoping medium-term that CSP can replace the use-case of #1.
Re: whitelist as a plugin
I'd like to see this tie into Pluggable WebViews because based on the work I'm doing on MozillaView, I think we're going to need it broken out into a plugin and an API added for it. That said, I'm hoping the delta isn't too different, because if we decide to completely redesign the Pluggable WebView API, I think it'll be another six months until this feature sees the light of day. On Fri, Oct 10, 2014 at 8:17 AM, Ian Clelland iclell...@chromium.org wrote: I'm still thinking in the old CadVer world here -- yes, it is a breaking change, and would absolutely require a major version change. 3.7.0 is certainly not a possible version number for it. I suppose the issue of master vs. 4.0.x in my head was whether the feature branch should be rooted on the branch named 4.0.x, and so depend on pluggable-webviews, or rooted on where master is today, and so be eligible for landing before the webview breakout. Of course, I'd really love both for pluggable webviews to ship, and to not have to do the whitelist work twice, so I'm happy with basing it on the 4.0.x branch. On Thu, Oct 9, 2014 at 2:28 PM, Andrew Grieve agri...@chromium.org wrote: It's technically a breaking change, so agree 4.0.x makes sense. On Thu, Oct 9, 2014 at 12:09 PM, Joe Bowser bows...@gmail.com wrote: This should land in 4.0.x On Oct 9, 2014 7:38 AM, Ian Clelland iclell...@chromium.org wrote: I'm running into more and more problems caused by the whitelist (today, it's because of the dual use of the internal whitelist for should be able to navigate to URL and should be able to XHR from URL) I'm going to start to pull it out, on a topic branch based off of Android 4.0.x right now. I'll create a JIRA issue to track the work. Is 4.0.x the best place for this to land, or is there any support for putting it on master as well, for an eventual 3.7 release? On Wed, Jul 9, 2014 at 1:22 PM, Shazron shaz...@gmail.com wrote: +1 to remove it for all the above reasons (and WKWebView in iOS 8) Those interested in this security blanket for checkmark ✓ purposes can install the plugin, and perhaps maintain it as well. On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux b...@brian.io wrote: Or remove it altogether and let the evolution of that code be maintained by those interested in the narrative it provides? :) On Wednesday, July 9, 2014, Andrew Grieve agri...@chromium.org wrote: Sounds like we both agree that it doesn't work and adds a false sense of security (to those that do opt into it) :P. Maybe what we should do is redesign the whitelist to do something more useful. e.g. A whitelist that says what URLs you can navigate to is useful and easy to implement. Let's just drop the trying to stop network requests aspect of it? On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser bows...@gmail.com javascript:; wrote: I'm in agreement with Andrew on this one. If we can get CSP working, that's a far better solution than our Whitelist, which was done because it was needed at the time for the enterprise use case that IBM had. I don't think we're ever going to stop are users from doing dumb things like including thirdpartyadnetworkthatdoesnoteusehttps.js in their apps any time soon, but they'll have to jump through more hoops to do dumb things, and making dumb things harder is a good thing. On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux b...@brian.io javascript:; wrote: Heh. Why do we always seem to be at the opposite end of considerations? (Not a bad thing anyhow. ;) So making whitelist a plugin would most certainly isolate the code which would help us better understand: 1.) where the surface for bugs are (we seem to miss/find new security holes each quarter…) 2.) if people actually use it I'm more interested in #2. I suspect the only people whom do use it are security researchers disproving the whitelist veracity. I feel this API was a mistake, is misleading, and ultimately leads to poor web security practices wrt 3rd part scripts. I'd like the evidence to remove it completely and making it a plugin would do that. (And still allow for its existence to those whom want to contribute to a marketing based api.) On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve agri...@chromium.org javascript:; wrote: I don't think moving the whitelist to a plugin would aid in its understanding. Right now the whitelist is used for two things:
Re: Independent platform release summary
I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now. Only thing holding back the release now is consensus on the version of the cli. It seemed like most people were leaning toward 10.0.0. Should I move forward with that? I would just have to branch + pin deps Leo the documentation version dropdown box would be tied to cli version. It still makes sense to copy over platform documentation into platform repos and maybe copy it into docs during generation time. As for plugin pinning, plugins have more to do with platforms. I wouldn't say they aren't tied to the cli at all. I understand your point though. So far, we haven't had any plugins that won't work with previous versions (As far as I know). We should really fix the engine stuff for plugins so we can keep track of what platforms they work for. I'd like us to give warnings to users to update their plugins if newer versions are out. Cordova info should also dump what versions of plugins you have installed if it doesn't already. In combination with cordova --save cordova --restore, we should be able to recommend a workflow that is easily reproducible on any machine. On Thu, Oct 9, 2014 at 1:44 PM, Chuck Lantz cla...@microsoft.com wrote: Okay - so - there's a pretty nasty CLI blocker bug right now. Plugins with dependencies don't install (this affects all platforms). In my opinion, we need to get a CLI release out really soon. Are we closed on this topic, or do we need to look at doing the old process to get this out the door while we are still talking? There are also a series of other bugs in the currently tagged 3.6.4 platforms for Android, Windows, and Windows Phone 8. These can be handled independently, but the CLI bug can't. https://issues.apache.org/jira/browse/CB-7670 -Chuck -Original Message- From: Treggiari, Leo [mailto:leo.treggi...@intel.com] Sent: Thursday, October 9, 2014 12:23 PM To: Michal Mocny Cc: Marcel Kinard; dev Subject: RE: Independent platform release summary I'll have to admit that this seems a bit weird. That is, independent versions of the CLI and platforms, with a Cordova release named something - e.g. a date? Imagine a user wants to know whether the new whitelist entry in config.xml is supported in the versions of CLI and platforms that they have - assuming
Re: Independent platform release summary
5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now. Only thing holding back the release now is consensus on the version of the cli. It seemed like most people were leaning toward 10.0.0. Should I move forward with that? I would just have to branch + pin deps Leo the documentation version dropdown box would be tied to cli version. It still makes sense to copy over platform documentation into platform repos and maybe copy it into docs during generation time. As for plugin pinning, plugins have more to do with platforms. I wouldn't say they aren't tied to the cli at all. I understand your point though. So far, we haven't had any plugins that won't work with previous versions (As far as I know). We should really fix the engine stuff for plugins so we can keep track of what platforms they work for. I'd like us to give warnings to users to update their plugins if newer versions are out. Cordova info should also dump what versions of plugins you have installed if it doesn't already. In combination with cordova --save cordova --restore, we should be able to recommend a workflow that is easily reproducible on any machine. On Thu, Oct 9, 2014 at 1:44 PM, Chuck Lantz cla...@microsoft.com wrote: Okay - so - there's a pretty nasty CLI blocker bug right now. Plugins with dependencies don't install (this affects all platforms). In my opinion, we need to get a CLI release out really soon. Are we closed on this topic, or do we need to look at doing the old process to get this out the door while we are still talking? There are also a series of other bugs in the currently tagged 3.6.4 platforms for Android, Windows, and Windows Phone 8. These can be handled independently, but the CLI bug can't. https://issues.apache.org/jira/browse/CB-7670 -Chuck -Original Message- From: Treggiari, Leo [mailto:leo.treggi...@intel.com] Sent: Thursday, October 9, 2014 12:23 PM To: Michal Mocny Cc: Marcel Kinard; dev Subject: RE: Independent platform release summary I'll have to admit that this seems a bit weird. That is, independent versions of the CLI and platforms, with a Cordova
Re: Independent platform release summary
As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now. Only thing holding back the release now is consensus on the version of the cli. It seemed like most people were leaning toward 10.0.0. Should I move forward with that? I would just have to branch + pin deps Leo the documentation version dropdown box would be tied to cli version. It still makes sense to copy over platform documentation into platform repos and maybe copy it into docs during generation time. As for plugin pinning, plugins have more to do with platforms. I wouldn't say they aren't tied to the cli at all. I understand your point though. So far, we haven't had any plugins that won't work with previous versions (As far as I know). We should really fix the engine stuff for plugins so we can keep track of what platforms they work for. I'd like us to give warnings to users to update their plugins if newer versions are out. Cordova info should also dump what versions of plugins you have installed if it doesn't already. In combination with cordova --save cordova --restore, we should be able to recommend a workflow that is easily reproducible on any machine. On Thu, Oct 9, 2014 at 1:44 PM, Chuck Lantz cla...@microsoft.com wrote: Okay - so - there's a pretty nasty CLI blocker bug right now. Plugins with dependencies don't install (this affects all platforms). In my opinion, we need to get a CLI release out really soon. Are we closed on this topic, or do we need to look at doing the old process to get this out the door while we are still talking? There are also a series of other bugs in the currently tagged 3.6.4 platforms for Android, Windows, and Windows Phone 8. These can be handled
RE: Independent platform release summary
I would prefer 4 as well. I asked in the hangout and the answer was that 4 was not good because Android had/is releasing a platform version 4. However if the CLI and platform version numbers will be unrelated going forward, it doesn't seem as if that should matter. Leo -Original Message- From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian LeRoux Sent: Friday, October 10, 2014 9:49 AM To: dev@cordova.apache.org Subject: Re: Independent platform release summary As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now. Only thing holding back the release now is consensus on the version of the cli. It seemed like most people were leaning toward 10.0.0. Should I move forward with that? I would just have to branch + pin deps Leo the documentation version dropdown box would be tied to cli version. It still makes sense to copy over platform documentation into platform repos and maybe copy it into docs during generation time. As for plugin pinning, plugins have more to do with platforms. I wouldn't say they aren't tied to the cli at all. I understand your point though. So far, we haven't had any plugins that won't work with previous versions (As far as I know). We should really fix the engine stuff for plugins so we can keep track of what platforms they work for. I'd like us to give warnings to users to update their plugins if newer versions are out. Cordova info should also dump what versions of plugins you have installed if it doesn't already. In combination with cordova --save cordova --restore, we should be able to recommend a workflow that is easily reproducible on any machine. On Thu, Oct 9, 2014 at 1:44 PM, Chuck Lantz cla...@microsoft.com wrote: Okay - so -
Re: Independent platform release summary
On Thu, Oct 9, 2014 at 3:22 PM, Treggiari, Leo leo.treggi...@intel.com
wrote:
I’ll have to admit that this seems a bit weird. That is, independent
versions of the CLI and platforms, with a “Cordova release” named
“something” – e.g. a date?
The Cordova Release can be labelled with the CLI version number. That
number just doesn't make sense to apply to all platforms, and is harmful to
some of our goals.
Imagine a user wants to know whether the new whitelist entry in config.xml
is supported in the versions of CLI and platforms that they have – assuming
they understand the distinction between the CLI and platforms to begin
with. They use some command to list the versions of the “things” (CLI and
platforms) they have installed. They go to the individual documentation of
the “things” and try to figure it out.
Okay, great question. Heres how I think that would play out:
First, we add this new config.xml feature to the CLI. We document this in
the CLI documentation, and should be obvious which CLI versions to support
this feature.
If this feature also required platform changes:
- Ideally, we implement the CLI change in a way that just warns when the
platform is too old, and no-ops if so. This is actually historically
common (minus the warnings!).
- If that isn't possible, and the change will actually break existing
platforms, that means the CLI has to do a MAJOR revision bump.
- Platforms have engine tags to say they expect a particular CLI version
= x.y.z and (x+1).0.0, and so updates to CLI that are MAJOR require
updates to all platforms.
- You can downgrade your CLI, perhaps only locally using local node_module
installs, should you want to avoid this situation in an old project.
The way the Cordova documentation works today is nice with the combo box
where I can select a Cordova version – 3.6.0, 3.5.0, ... What would the
combo box contain in the new versioning scheme and how many entries would
there be? Are the answers “dates” and “lots of dates”? Or would there be
no Cordova version documentation other than an explanation of how to get
the list of “things” you currently have and where to find the documentation
on them.
As discussed, we would split CLI/platform docs and version alongside
releases (like plugins). In this case, you would probably be reading the
CLI docs for config.xml settings, and can follow a link to
platform-specific extensions.
To “pin” or not to “pin.
Note that, to me, the pinning choice defines what happens when I use
“cordova {plugin | platform} add foo” with no specific version specified.
Right.
I’ve understood, so far at least, that plugins are not pinned (an add
always fetches something) and platforms are pinned to a CLI version (an add
tells the CLI that I will be using that platform (already installed) for
this project). Everything I have read which includes 1 book and the
on-line project documentation, suggest that, even if not stating it
explicitly. E.g. plugins talk about “fetching” and platforms don’t. There
is a way to fetch a specific version of platform support. That’s good and
if I do that it is up to me to understand the compatibility of the specific
version I requested.
Is this true? If so then the npm cordova behavior seems weird. That is,
if I “npm install cordova” I get a set of pinned platforms. If I “npm
update cordova”, I get a new CLI and nothing else – i.e. not the platforms
that were pinned to that version of the CLI?
Few questions here..
Yes, plugins are not pinned in any way, they always install latest.
Yes, platforms are pinned, in that there is a pre-selected default version
that will be installed which is tied to the CLI version.
Yes, there are ways to explicitly override the default version of platform
/ plugin that gets installed.
Yes, when you update CLI on npm, you pinnings change, but no platforms
are actually upgraded anywhere. You don't even download the platforms at
this point, it just affects the next time you platform add somewhere.
Should the plugin and platform ‘pin’ behavior be the same?
Personally, I think so, but this is something we can decide later. Right
now there are already a lot of changes, and pinning has been what we've
done historically. There was a long thread about this and there were some
good reasons mentioned there for why this should continue for now (I don't
recall them, I can find and forward the thread).
Should both be pinned? Some may find this alternative “blasphemous” but
the core plugin versions tested with a version of the CLI could be pinned
to the version of the CLI.
Should both not be pinned? It would be more consistent and if users are
OK with plugins being unpinned, why not platforms?
But maybe plugins and platforms are different. Plugins are purely
run-time code. Platforms are primarily tooling with some run-time code.
Does that difference make the current pinning behavior the best choice.
Maybe,
Re: Independent platform release summary
4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now. Only thing holding back the release now is consensus on the version of the cli. It seemed like most people were leaning toward 10.0.0. Should I move forward with that? I would just have to branch + pin deps Leo the documentation version dropdown box would be tied to cli version. It still makes sense to copy over platform documentation into platform repos and maybe copy it into docs during generation time. As for plugin pinning, plugins have more to do with platforms. I wouldn't say they aren't tied to the cli at all. I understand your point though. So far, we haven't had any plugins that won't work with previous versions (As far as I know). We should really fix the engine stuff for plugins so we can keep track of what platforms they work for. I'd like us to give warnings to users to update their plugins if newer versions are out. Cordova info should also dump what versions of plugins you have installed if it doesn't already. In combination with cordova --save cordova --restore, we should be able to recommend a workflow that is easily reproducible on any machine. On Thu, Oct 9, 2014 at 1:44 PM, Chuck
Re: Independent platform release summary
Well, alright, I think I like that. All I care about is that we start to semver properly, and don't block platforms from releasing. Anyway, I'm not sure we should necessarily vote on this, but lets give it a day to sink in since it isn't what everyone agreed to at the meetup. -Michal On Fri, Oct 10, 2014 at 12:53 PM, Treggiari, Leo leo.treggi...@intel.com wrote: I would prefer 4 as well. I asked in the hangout and the answer was that 4 was not good because Android had/is releasing a platform version 4. However if the CLI and platform version numbers will be unrelated going forward, it doesn't seem as if that should matter. Leo -Original Message- From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian LeRoux Sent: Friday, October 10, 2014 9:49 AM To: dev@cordova.apache.org Subject: Re: Independent platform release summary As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now. Only thing holding back the release now is consensus on the version of the cli. It seemed like most people were leaning toward 10.0.0. Should I move forward with that? I would just have to branch + pin deps Leo the documentation version dropdown box would be tied to cli version. It still makes sense to copy over platform documentation into platform repos and maybe copy it into docs during generation time. As for plugin pinning, plugins have more to do with platforms. I wouldn't say they aren't tied to the cli at all. I understand your point though. So far, we haven't had any plugins that won't work with previous versions (As far as I know). We should really fix the engine stuff for plugins so we can keep track of what
Re: Independent platform release summary
OR we move to named releases externally. Cordova MX === 4.0 On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now. Only thing holding back the release now is consensus on the version of the cli. It seemed like most people were leaning toward 10.0.0. Should I move forward with that? I would just have to branch + pin deps Leo the documentation version dropdown box would be tied to cli version. It still makes sense to copy over platform documentation into platform repos and maybe copy it into docs during generation time. As for plugin pinning, plugins have more to do with platforms. I wouldn't say they aren't tied to the cli at all. I understand your point though. So far, we haven't had any plugins that won't work with previous versions (As far as I know). We should really fix the engine stuff for plugins so we can keep track of what platforms they work for. I'd like us to give warnings to users to update their plugins if newer versions are out. Cordova info should also dump what
RE: Independent platform release summary
Thanks for the answers and they make sense to me. Just a couple of follow-ons
– see [LEO] below.
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Friday, October 10, 2014 9:54 AM
To: Treggiari, Leo
Cc: Michal Mocny; Marcel Kinard; dev
Subject: Re: Independent platform release summary
On Thu, Oct 9, 2014 at 3:22 PM, Treggiari, Leo
leo.treggi...@intel.commailto:leo.treggi...@intel.com wrote:
I’ll have to admit that this seems a bit weird. That is, independent versions
of the CLI and platforms, with a “Cordova release” named “something” – e.g. a
date?
The Cordova Release can be labelled with the CLI version number. That number
just doesn't make sense to apply to all platforms, and is harmful to some of
our goals.
Imagine a user wants to know whether the new whitelist entry in config.xml is
supported in the versions of CLI and platforms that they have – assuming they
understand the distinction between the CLI and platforms to begin with. They
use some command to list the versions of the “things” (CLI and platforms) they
have installed. They go to the individual documentation of the “things” and
try to figure it out
Okay, great question. Heres how I think that would play out:
First, we add this new config.xml feature to the CLI. We document this in the
CLI documentation, and should be obvious which CLI versions to support this
feature.
[LEO] Will this happen before the “big change”? It would be nice if it did.
If this feature also required platform changes:
- Ideally, we implement the CLI change in a way that just warns when the
platform is too old, and no-ops if so. This is actually historically common
(minus the warnings!).
- If that isn't possible, and the change will actually break existing
platforms, that means the CLI has to do a MAJOR revision bump.
- Platforms have engine tags to say they expect a particular CLI version =
x.y.z and (x+1).0.0, and so updates to CLI that are MAJOR require updates to
all platforms.
- You can downgrade your CLI, perhaps only locally using local node_module
installs, should you want to avoid this situation in an old project.
The way the Cordova documentation works today is nice with the combo box where
I can select a Cordova version – 3.6.0, 3.5.0, ... What would the combo box
contain in the new versioning scheme and how many entries would there be? Are
the answers “dates” and “lots of dates”? Or would there be no Cordova version
documentation other than an explanation of how to get the list of “things” you
currently have and where to find the documentation on them.
As discussed, we would split CLI/platform docs and version alongside releases
(like plugins). In this case, you would probably be reading the CLI docs for
config.xml settings, and can follow a link to platform-specific extensions.
To “pin” or not to “pin”
Note that, to me, the pinning choice defines what happens when I use “cordova
{plugin | platform} add foo” with no specific version specified.
Right.
I’ve understood, so far at least, that plugins are not pinned (an add always
fetches something) and platforms are pinned to a CLI version (an add tells the
CLI that I will be using that platform (already installed) for this project).
Everything I have read which includes 1 book and the on-line project
documentation, suggest that, even if not stating it explicitly. E.g. plugins
talk about “fetching” and platforms don’t. There is a way to fetch a specific
version of platform support. That’s good and if I do that it is up to me to
understand the compatibility of the specific version I requested.
Is this true? If so then the npm cordova behavior seems weird. That is, if I
“npm install cordova” I get a set of pinned platforms. If I “npm update
cordova”, I get a new CLI and nothing else – i.e. not the platforms that were
pinned to that version of the CLI?
Few questions here..
Yes, plugins are not pinned in any way, they always install latest.
Yes, platforms are pinned, in that there is a pre-selected default version that
will be installed which is tied to the CLI version.
Yes, there are ways to explicitly override the default version of platform /
plugin that gets installed.
Yes, when you update CLI on npm, you pinnings change, but no platforms are
actually upgraded anywhere. You don't even download the platforms at this
point, it just affects the next time you platform add somewhere.
[LEO] I get the last distinction (npm update) now and didn’t before. That
makes sense, but would be better if it were well documented. Maybe it is and I
just didn’t see it.
Should the plugin and platform ‘pin’ behavior be the same?
Personally, I think so, but this is something we can decide later. Right now
there are already a lot of changes, and pinning has been what we've done
historically. There was a long thread about this and there were some good
reasons mentioned there for why this should continue for now (I don't recall
Re: Independent platform release summary
On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now. Only thing holding back the release now is consensus on the version of the cli. It seemed like most people were leaning toward 10.0.0. Should I move forward with that? I would just have to branch + pin deps Leo the documentation version dropdown box would be tied to cli version. It still makes sense to copy over platform documentation into platform repos and maybe copy it into docs during generation time. As for plugin pinning, plugins have more to do with platforms. I wouldn't say they aren't tied to the cli at all. I understand your point though. So far, we haven't had any plugins that won't work with previous versions (As far as I know). We should really fix the engine stuff for
[GitHub] cordova-plugin-file pull request: CB-7700 cordova-plugin-file docu...
GitHub user sosahvictor opened a pull request: https://github.com/apache/cordova-plugin-file/pull/86 CB-7700 cordova-plugin-file documentation translation CB-7700 cordova-plugin-file documentation translation: cordova-plugin-file You can merge this pull request into a Git repository by running: $ git pull https://github.com/sosahvictor/cordova-plugin-file master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-file/pull/86.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #86 commit 143764054690ecbbf89769626ce08d841c9fc6af Author: Victor Sosa victo...@mx1.ibm.com Date: 2014-10-10T16:46:19Z CB-7700 cordova-plugin-file documentation translation: cordova-plugin-file --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-docs pull request: CB-7700 cordova-docs documentation tran...
GitHub user sosahvictor opened a pull request: https://github.com/apache/cordova-docs/pull/241 CB-7700 cordova-docs documentation translation CB-7700 cordova-docs documentation translation: cordova-docs You can merge this pull request into a Git repository by running: $ git pull https://github.com/sosahvictor/cordova-docs master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-docs/pull/241.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #241 commit 809a66a2b2871dc0f7095b42c43b5cdef8bd74ae Author: Victor Sosa victo...@mx1.ibm.com Date: 2014-10-10T16:43:32Z CB-7700 cordova-docs documentation translation: cordova-docs --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-file-transfer pull request: CB-7700 cordova-plugin-...
GitHub user sosahvictor opened a pull request: https://github.com/apache/cordova-plugin-file-transfer/pull/45 CB-7700 cordova-plugin-file-transfer documentation translation CB-7700 cordova-plugin-file-transfer documentation translation: cordova-plugin-file-transfer You can merge this pull request into a Git repository by running: $ git pull https://github.com/sosahvictor/cordova-plugin-file-transfer master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-file-transfer/pull/45.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #45 commit df6a4fed2e3b96e38b149ccc9bdefeafbbbf73d5 Author: Victor Sosa victo...@mx1.ibm.com Date: 2014-10-10T16:46:50Z CB-7700 cordova-plugin-file-transfer documentation translation: cordova-plugin-file-transfer --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-network-information pull request: CB-7700 cordova-p...
GitHub user sosahvictor opened a pull request: https://github.com/apache/cordova-plugin-network-information/pull/21 CB-7700 cordova-plugin-network-information documentation translation CB-7700 cordova-plugin-network-information documentation translation: cordova-plugin-network-information You can merge this pull request into a Git repository by running: $ git pull https://github.com/sosahvictor/cordova-plugin-network-information master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-network-information/pull/21.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #21 commit 9c193676f9bb268099f76e3473b8b8a2b8e77366 Author: Victor Sosa victo...@mx1.ibm.com Date: 2014-10-10T16:48:33Z CB-7700 cordova-plugin-network-information documentation translation: cordova-plugin-network-information --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Independent platform release summary
lol... I like that :P 2014-10-10 12:09 GMT-05:00 Joe Bowser bows...@gmail.com: On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now. Only thing holding back the release now is consensus on the version of the cli. It seemed like most people were leaning toward 10.0.0. Should I move forward with that? I would just have to branch + pin deps Leo the documentation version dropdown box would be tied to cli version. It still makes sense to copy over platform documentation into platform repos and maybe copy it into docs during generation time. As for plugin pinning, plugins have more to do with platforms. I wouldn't
iOS 8.1 testing
I have gone through the mobilespec tests on 8.1 beta 2 and so far everything is looking good. Looks like the only API diffs are methods and constants that got added. Thanks, Edna Morales
Re: Independent platform release summary
4.0 is also good. Should we tag and start a vote for that ? Sorry for asking about vote again, but I want to ensure that the issues that Sergey fixed in the CLI/Lib are impacting some folks and I hope this release could help them fast. On 10/10/14, 10:17 AM, Victor Sosa sosah.vic...@gmail.com wrote: lol... I like that :P 2014-10-10 12:09 GMT-05:00 Joe Bowser bows...@gmail.com: On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now. Only thing holding back the release now is consensus on the version of the cli. It seemed like most people were leaning toward 10.0.0. Should I move forward with that? I would just have to branch + pin deps Leo the documentation version dropdown box
Re: Independent platform release summary
4.0 is good. Let's move. @purplecabbage risingj.com On Fri, Oct 10, 2014 at 10:54 AM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: 4.0 is also good. Should we tag and start a vote for that ? Sorry for asking about vote again, but I want to ensure that the issues that Sergey fixed in the CLI/Lib are impacting some folks and I hope this release could help them fast. On 10/10/14, 10:17 AM, Victor Sosa sosah.vic...@gmail.com wrote: lol... I like that :P 2014-10-10 12:09 GMT-05:00 Joe Bowser bows...@gmail.com: On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary I think vladimir fixed the bug. We just need to release now.
Re: Independent platform release summary
Should we consider jumping to 13? You know... just prefix a 1 onto the existing number. 4.0 (or any other number) is great by me! On Fri, Oct 10, 2014 at 1:54 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: 4.0 is also good. Should we tag and start a vote for that ? Sorry for asking about vote again, but I want to ensure that the issues that Sergey fixed in the CLI/Lib are impacting some folks and I hope this release could help them fast. On 10/10/14, 10:17 AM, Victor Sosa sosah.vic...@gmail.com wrote: lol... I like that :P 2014-10-10 12:09 GMT-05:00 Joe Bowser bows...@gmail.com: On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing. -Chuck -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, October 9, 2014 2:13 PM To: dev@cordova.apache.org Cc: Michal Mocny; Marcel Kinard Subject: Re: Independent platform release summary
Re: Independent platform release summary
4.0 and let's move on. It's just a number, and is a minor point in the end. On Fri, Oct 10, 2014 at 10:57 AM, Andrew Grieve agri...@chromium.org wrote: Should we consider jumping to 13? You know... just prefix a 1 onto the existing number. 4.0 (or any other number) is great by me! On Fri, Oct 10, 2014 at 1:54 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: 4.0 is also good. Should we tag and start a vote for that ? Sorry for asking about vote again, but I want to ensure that the issues that Sergey fixed in the CLI/Lib are impacting some folks and I hope this release could help them fast. On 10/10/14, 10:17 AM, Victor Sosa sosah.vic...@gmail.com wrote: lol... I like that :P 2014-10-10 12:09 GMT-05:00 Joe Bowser bows...@gmail.com: On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main message is that when you platform add android, you may see an npm pull for cordova-android@4.3.2 and that is expected. It's just formalizing the message and allows independent platform rev'ing.
Re: Independent platform release summary
Alright, 4.0. On Fri, Oct 10, 2014 at 11:06 AM, Shazron shaz...@gmail.com wrote: 4.0 and let's move on. It's just a number, and is a minor point in the end. On Fri, Oct 10, 2014 at 10:57 AM, Andrew Grieve agri...@chromium.org wrote: Should we consider jumping to 13? You know... just prefix a 1 onto the existing number. 4.0 (or any other number) is great by me! On Fri, Oct 10, 2014 at 1:54 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: 4.0 is also good. Should we tag and start a vote for that ? Sorry for asking about vote again, but I want to ensure that the issues that Sergey fixed in the CLI/Lib are impacting some folks and I hope this release could help them fast. On 10/10/14, 10:17 AM, Victor Sosa sosah.vic...@gmail.com wrote: lol... I like that :P 2014-10-10 12:09 GMT-05:00 Joe Bowser bows...@gmail.com: On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova 3.4.1 was 3.4.0 for all platforms but iOS. The main
Re: Independent platform release summary
Ok, 4.0 On 10/10/14, 2:08 PM, Steven Gill stevengil...@gmail.com wrote: Alright, 4.0. On Fri, Oct 10, 2014 at 11:06 AM, Shazron shaz...@gmail.com wrote: 4.0 and let's move on. It's just a number, and is a minor point in the end. On Fri, Oct 10, 2014 at 10:57 AM, Andrew Grieve agri...@chromium.org wrote: Should we consider jumping to 13? You know... just prefix a 1 onto the existing number. 4.0 (or any other number) is great by me! On Fri, Oct 10, 2014 at 1:54 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: 4.0 is also good. Should we tag and start a vote for that ? Sorry for asking about vote again, but I want to ensure that the issues that Sergey fixed in the CLI/Lib are impacting some folks and I hope this release could help them fast. On 10/10/14, 10:17 AM, Victor Sosa sosah.vic...@gmail.com wrote: lol... I like that :P 2014-10-10 12:09 GMT-05:00 Joe Bowser bows...@gmail.com: On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is still predictable). Leo - I think at least out of the gate devs will likely focus on the CLI version as primary. Basically today, the cadence version of the CLI is what people talk about. Heck, Cordova
[GitHub] cordova-coho pull request: [CB-7744] Add support for git-depth fla...
Github user purplecabbage commented on the pull request: https://github.com/apache/cordova-coho/pull/52#issuecomment-58695256 We should stop closing issues from other repositories, since @asfgit closing it does not give us any more info. Looking at cordova-coho and elsewhere, I still see no mention of 52, so this one is a mystery. Here is a 'multi repo close issues' commit message: ``` close apache/cordova-lib#94 close #39 close apache/cordova-android#120 close apache/cordova-android#123 ``` At least a practice of only closing from the repo with the pull request would make this a bit easier to track down. Magic is powerful, use it wisely. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-coho pull request: [CB-7744] Add support for git-depth fla...
Github user sgrebnov commented on the pull request: https://github.com/apache/cordova-coho/pull/52#issuecomment-58696669 @agrieve, @purplecabbage thx for looking on this! I've asked @MariaBukharina to send PR one more time w/o 'd' alias for '--depth' arg since we use -d for debug in other places. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Independent platform release summary
4.0! woo hoo. On Fri, Oct 10, 2014 at 2:10 PM, Josh Soref jso...@blackberry.com wrote: Ok, 4.0 On 10/10/14, 2:08 PM, Steven Gill stevengil...@gmail.com wrote: Alright, 4.0. On Fri, Oct 10, 2014 at 11:06 AM, Shazron shaz...@gmail.com wrote: 4.0 and let's move on. It's just a number, and is a minor point in the end. On Fri, Oct 10, 2014 at 10:57 AM, Andrew Grieve agri...@chromium.org wrote: Should we consider jumping to 13? You know... just prefix a 1 onto the existing number. 4.0 (or any other number) is great by me! On Fri, Oct 10, 2014 at 1:54 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: 4.0 is also good. Should we tag and start a vote for that ? Sorry for asking about vote again, but I want to ensure that the issues that Sergey fixed in the CLI/Lib are impacting some folks and I hope this release could help them fast. On 10/10/14, 10:17 AM, Victor Sosa sosah.vic...@gmail.com wrote: lol... I like that :P 2014-10-10 12:09 GMT-05:00 Joe Bowser bows...@gmail.com: On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote: Yeah agreed - Vladimir squashed the bug and what was at once point to be called 3.7.0 has been mainly waiting on a version number. Personally I am fine with 10.0.0 or 5.0.0 - Either send the message that platform versions are divorced from the CLI from a versioning perspective (though behavior is
Re: Independent platform release summary
I am sure Microsoft had a much longer discussion before deciding on Windows 10, and probably the same goes for Android L Happy to be moving ... @purplecabbage risingj.com On Fri, Oct 10, 2014 at 11:29 AM, Michal Mocny mmo...@chromium.org wrote: 4.0! woo hoo. On Fri, Oct 10, 2014 at 2:10 PM, Josh Soref jso...@blackberry.com wrote: Ok, 4.0 On 10/10/14, 2:08 PM, Steven Gill stevengil...@gmail.com wrote: Alright, 4.0. On Fri, Oct 10, 2014 at 11:06 AM, Shazron shaz...@gmail.com wrote: 4.0 and let's move on. It's just a number, and is a minor point in the end. On Fri, Oct 10, 2014 at 10:57 AM, Andrew Grieve agri...@chromium.org wrote: Should we consider jumping to 13? You know... just prefix a 1 onto the existing number. 4.0 (or any other number) is great by me! On Fri, Oct 10, 2014 at 1:54 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: 4.0 is also good. Should we tag and start a vote for that ? Sorry for asking about vote again, but I want to ensure that the issues that Sergey fixed in the CLI/Lib are impacting some folks and I hope this release could help them fast. On 10/10/14, 10:17 AM, Victor Sosa sosah.vic...@gmail.com wrote: lol... I like that :P 2014-10-10 12:09 GMT-05:00 Joe Bowser bows...@gmail.com: On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait 72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version up to 10.0.0. On Thu, Oct 9, 2014 at 2:45 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: Lets start with a vote for 10.0.0 ? And if someone feels strongly about calling it something the vote could be cancelled !! On 10/9/14, 2:41 PM, Chuck Lantz cla...@microsoft.com wrote:
RE: Independent platform release summary
Yeah we were joking that we were fine with Apache Cordova 10, but not Apache Cordova X --- ACX is too Apple. :) -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Friday, October 10, 2014 11:37 AM To: dev@cordova.apache.org Subject: Re: Independent platform release summary I am sure Microsoft had a much longer discussion before deciding on Windows 10, and probably the same goes for Android L Happy to be moving ... @purplecabbage risingj.com On Fri, Oct 10, 2014 at 11:29 AM, Michal Mocny mmo...@chromium.org wrote: 4.0! woo hoo. On Fri, Oct 10, 2014 at 2:10 PM, Josh Soref jso...@blackberry.com wrote: Ok, 4.0 On 10/10/14, 2:08 PM, Steven Gill stevengil...@gmail.com wrote: Alright, 4.0. On Fri, Oct 10, 2014 at 11:06 AM, Shazron shaz...@gmail.com wrote: 4.0 and let's move on. It's just a number, and is a minor point in the end. On Fri, Oct 10, 2014 at 10:57 AM, Andrew Grieve agri...@chromium.org wrote: Should we consider jumping to 13? You know... just prefix a 1 onto the existing number. 4.0 (or any other number) is great by me! On Fri, Oct 10, 2014 at 1:54 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: 4.0 is also good. Should we tag and start a vote for that ? Sorry for asking about vote again, but I want to ensure that the issues that Sergey fixed in the CLI/Lib are impacting some folks and I hope this release could help them fast. On 10/10/14, 10:17 AM, Victor Sosa sosah.vic...@gmail.com wrote: lol... I like that :P 2014-10-10 12:09 GMT-05:00 Joe Bowser bows...@gmail.com: On Oct 10, 2014 10:05 AM, Brian LeRoux b...@brian.io wrote: OR we move to named releases externally. Cordova MX === 4.0 Cordova Mexico? On Oct 10, 2014 10:03 AM, Michal Mocny mmo...@chromium.org wrote: 4 was also discussed as fine, and in isolation would have been our choice for sure -- but we worried that with the impending cordova-4.0 releases, it would confuse users and not mark a clear departure from cadver. The more I think about it though, the less important I think that worry is. Maybe 4.0 is fine. (Apologies to Steve, who just wants to get this over with) On Fri, Oct 10, 2014 at 12:48 PM, Brian LeRoux b...@brian.io wrote: As is 4. This is more of an outreach, marketing, blogging, tweeting, etc problem. Versions are for issue tracking not marketing. (Tho semver and our respective $BIGCO's confuse that to their and our continued strife.) (All IMO of course, happy to follow the wisdom of the crowd on this one.) On Oct 10, 2014 9:29 AM, Michal Mocny mmo...@chromium.org wrote: 5 is also fine. On Fri, Oct 10, 2014 at 12:17 PM, Brian LeRoux b...@brian.io wrote: I am against it. Its not going to achieve the goal of alleviating confusion. People see the CLI as the version not the platforms. I'd rather we went to 5 if anything. On Oct 9, 2014 3:56 PM, Parashuram Narasimhan (MS OPEN TECH) panar...@microsoft.com wrote: I meant tag and start the vote for the next release :) On 10/9/14, 3:01 PM, Chuck Lantz cla...@microsoft.com wrote: +1 -Chuck -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, October 9, 2014 2:55 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary +1 to not voting ;) , it implies we will wait +72 hours before moving on. How about if anyone is completely against 10.0.0 they voice it here, in the next couple hours, otherwise we move forward. @purplecabbage risingj.com On Thu, Oct 9, 2014 at 2:52 PM, Steven Gill stevengil...@gmail.com wrote: I don't think a vote is necessary. I'd hate to see us resort to voting to solve problems. Voting should be a last resort if consensus is split. I don't see that in this scenario. I propose we bumb the version
Re: [GitHub] cordova-coho pull request: [CB-7744] Add support for git-depth fla...
Good call. On Fri, Oct 10, 2014 at 2:14 PM, purplecabbage g...@git.apache.org wrote: Github user purplecabbage commented on the pull request: https://github.com/apache/cordova-coho/pull/52#issuecomment-58695256 We should stop closing issues from other repositories, since @asfgit closing it does not give us any more info. Looking at cordova-coho and elsewhere, I still see no mention of 52, so this one is a mystery. Here is a 'multi repo close issues' commit message: ``` close apache/cordova-lib#94 close #39 close apache/cordova-android#120 close apache/cordova-android#123 ``` At least a practice of only closing from the repo with the pull request would make this a bit easier to track down. Magic is powerful, use it wisely. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-globalization pull request: [CB-7766] Add quirk not...
GitHub user martincgg opened a pull request: https://github.com/apache/cordova-plugin-globalization/pull/28 [CB-7766] Add quirk note about android navigator.globalization.dateToString A note to clarify, that the value obtained using dateToString uses the UTS#35 and is not completely aligned with ICU standard. You can merge this pull request into a Git repository by running: $ git pull https://github.com/martincgg/cordova-plugin-globalization CB-7766 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-globalization/pull/28.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #28 commit 586c50c8a94f759fbb61053e37c54af54439869f Author: Martin Gonzalez martin.c.glez.g...@gmail.com Date: 2014-10-10T22:01:40Z [CB-7766] Add quirk note about android dateToString A note to clarify, that the value obtained using dateToString uses the UTS#35 and is not completely aligned with ICU standard. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[Vote] Tools Release
Please review and vote on this Tools Release. Release issue: https://issues.apache.org/jira/browse/CB-7661 Tools have been published to dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-7661/ The packages were published from their corresponding git tags: cordova-js: 3.7.1 (f5046c9665) cordova-lib: 4.0.0 (f5db3d13d5) cordova-plugman: 0.22.12 (203706aac1) cordova-cli: 4.0.0 (0fb8fbb189) Upon a successful vote I will upload the archives to dist/, publish them to NPM under the latest tag, and post the corresponding blog post. Voting guidelines: https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md Voting will go on for a minimum of 48 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Ran coho check-license to ensure all dependencies and subdependencies have Apache-compatible licenses * Ensured continuous build was green when repos were tagged
Re: [VOTE] Plugins Release Oct 3, 2014
We need one more vote to publish On Mon, Oct 6, 2014 at 8:18 PM, Sergey Grebnov (Akvelon) v-seg...@microsoft.com wrote: I vote +1 * Verified signatures and hashes * Verified tags * Checked plugin functionality with mobilespec app for windows and wp8 platforms * Checked release notes Thx! Sergey -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Saturday, October 4, 2014 4:22 AM To: dev@cordova.apache.org Subject: [VOTE] Plugins Release Oct 3, 2014 Please review and vote on the release of this plugins release. Release issue: https://issues.apache.org/jira/browse/CB-7699 The plugins have been published to dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-7699/ The packages were published from their corresponding git tags: cordova-plugin-camera: 0.3.3 (021743f20e) cordova-plugin-contacts: 0.2.14 (a9df3c4fa0) cordova-plugin-file-transfer: 0.4.7 (d0d8698af1) cordova-plugin-globalization: 0.3.2 (6485890999) cordova-plugin-inappbrowser: 0.5.2 (8ce6b497fa) cordova-plugin-media: 0.2.14 (35ab3af539) cordova-plugin-media-capture: 0.3.4 (852a053993) cordova-plugin-network-information: 0.2.13 (056c6dddaf) cordova-plugin-splashscreen: 0.3.4 (b46cdca795) Upon a successful vote I will upload the archives to dist/, upload them to the Plugins Registry, and post the corresponding blog post. Voting guidelines: https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md Voting will go on for a minimum of 48 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Used `license-checker` to ensure all dependencies have Apache-compatible licenses - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [VOTE] Plugins Release Oct 3, 2014
+1 Verified Signatures, tags and functionality. On 10/10/14, 3:50 PM, Steven Gill stevengil...@gmail.com wrote: We need one more vote to publish On Mon, Oct 6, 2014 at 8:18 PM, Sergey Grebnov (Akvelon) v-seg...@microsoft.com wrote: I vote +1 * Verified signatures and hashes * Verified tags * Checked plugin functionality with mobilespec app for windows and wp8 platforms * Checked release notes Thx! Sergey -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Saturday, October 4, 2014 4:22 AM To: dev@cordova.apache.org Subject: [VOTE] Plugins Release Oct 3, 2014 Please review and vote on the release of this plugins release. Release issue: https://issues.apache.org/jira/browse/CB-7699 The plugins have been published to dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-7699/ The packages were published from their corresponding git tags: cordova-plugin-camera: 0.3.3 (021743f20e) cordova-plugin-contacts: 0.2.14 (a9df3c4fa0) cordova-plugin-file-transfer: 0.4.7 (d0d8698af1) cordova-plugin-globalization: 0.3.2 (6485890999) cordova-plugin-inappbrowser: 0.5.2 (8ce6b497fa) cordova-plugin-media: 0.2.14 (35ab3af539) cordova-plugin-media-capture: 0.3.4 (852a053993) cordova-plugin-network-information: 0.2.13 (056c6dddaf) cordova-plugin-splashscreen: 0.3.4 (b46cdca795) Upon a successful vote I will upload the archives to dist/, upload them to the Plugins Registry, and post the corresponding blog post. Voting guidelines: https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md Voting will go on for a minimum of 48 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Used `license-checker` to ensure all dependencies have Apache-compatible licenses - 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: iOS 8.1 testing
Thanks Edna! On Fri, Oct 10, 2014 at 10:34 AM, Edna Y Morales eymor...@us.ibm.com wrote: I have gone through the mobilespec tests on 8.1 beta 2 and so far everything is looking good. Looks like the only API diffs are methods and constants that got added. Thanks, Edna Morales
[iOS] tests
They have been converted to jasmine. Right now there are two test suites: 1. cordova-lib tests (runs the unit tests) 2. create tests (tests different ways to create a project)
[GitHub] cordova-plugin-geolocation pull request: iOS: Clearing all Watches...
Github user shazron commented on the pull request: https://github.com/apache/cordova-plugin-geolocation/pull/25#issuecomment-58731667 Please file an issue for Android at: http://issues.apache.org/jira/browse/CB ... so it can be tracked and evaluated by the devs, and you can be notified. Sign up here: https://issues.apache.org/jira/secure/Signup!default.jspa Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-android pull request: Ignore --device option in Android bu...
GitHub user dpogue opened a pull request: https://github.com/apache/cordova-android/pull/127 Ignore --device option in Android build iOS uses the `--device` flag to indicate that it should build for the device rather than the simulator. Until recently, Android simply ignored this option. Now it throws an error. This causes problems for people targeting multiple platforms with the CLI tools, because a command like `cordova build --release --device` will now fail on Android, rather than building both Android and iOS versions of the app. **Simple test case:** ```bash $ cordova init myapp $ cd ./myapp $ cordova platform add ios android $ cordova build --release --device --verbose ``` You can merge this pull request into a Git repository by running: $ git pull https://github.com/dpogue/cordova-android patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-android/pull/127.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #127 commit 138b24b6865a37ebbc08336c23117629f961cd83 Author: Darryl Pogue dvpdin...@gmail.com Date: 2014-10-11T05:04:17Z Ignore --device option in android build iOS uses the `--device` flag to indicate that it should build for the device rather than the simulator. Until recently, Android simply ignored this option. Now it throws an error. This causes problems for people targeting multiple platforms with the CLI tools, because a command like `cordova build --release --device` will now fail on Android, rather than building both Android and iOS versions of the app. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
