Re: archiving older platforms
+1 to negligence, or might it be ignorance? The attic sounds like its where you put code you're ashamed of. Cheers, Jesse Sent from my iPhone5.5 On 2013-03-21, at 3:41 PM, Brian LeRoux wrote: Attic seems like more work than outright neglect. Might be for conceptual purity we want to move Bada there but I could see Qt and webOS rising from their slumber. On Thu, Mar 21, 2013 at 3:30 PM, Anis KADRI wrote: > and no apache attic [1] ? > > [1] http://attic.apache.org/ > > > On Thu, Mar 21, 2013 at 3:28 PM, Brian LeRoux wrote: > >> This means we're going to leave Bada, Qt, webOS at their latest tags, >> and not dist. (Code still accessible, etc.) >> >> We'll continue as normal for BB, for now. >> >> >> >> On Thu, Mar 21, 2013 at 3:09 PM, Gord Tanner wrote: >>> I am confused, who are the stewards and what platforms are being >> stewarded? >>> >>> Sent from my iPhone >>> >>> On 2013-03-21, at 6:00 PM, Filip Maj wrote: >>> +1 On 3/21/13 2:12 PM, "Shazron" wrote: > +1 > > > On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny >> wrote: > >> +1 >> >> >> On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: >> >>> Ok, I think we have agreement that we'll put these guys on hold until >>> they find a steward. This means: >>> >>> - we won't be taggin them further >>> - we won't be including them in a release >>> >>> This does not mean: >>> >>> - deletion or archiving or attic for the src >>> >>> (Think of it as a pause button!) >>> >>> Agree/disagree? >>> >>> On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve >> >>> wrote: If there are no fixes going into these platforms, then there is no >>> benefit in their users updating them to newer versions of Cordova. There's going to be more refactoring required when moving plugins to >>> their own repos. We'll really need owners for all platforms that will make >> the transition, or else we won't have any way to test that the >> refactoring hasn't broken a platform. On specific example is that blackberry's >> JS >>> repo is really 4-in-1 currently, and our plugin spec doesn't have support >> for this. They will need to be split out into 4 separate platforms, at >> least >>> as far as the JS is concerned. So... I guess my +1 is just for any platform that doesn't have a >> someone willing to focus on it. E.g. I'm fine with keeping WebOS around if >> Markus wants to do the work to support it through this transition. On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis >> >>> wrote: > > We will try to provide relevant stats on platform adoption as we >> are >>> able. > I am anxiously awaiting that information myself. ;) > > While lacking this information, I still feel that BBOS will be >> with us >>> for > a deal of time, particularly in the enterprise where we are seeing >> a > significant trend towards Cordova/PhoneGap/WebWorks as the primary >>> platform > of choice for apps. This is, frustratingly, a difficult market to >> get > adequate metrics out of, as they will typically not use PhoneGap >> Build >>> IMO, > and they don't deploy to commercial application stores. A bit of a >> black > box, but our enterprise support teams continually support the >> notion >>> that > enterprise looks at HTML5 apps first. > > In this regard, we would like to see support for BBOS be >> maintained in >>> the > short term. Our team is focused on bringing up BlackBerry 10 built >> on > Cordova, and once that has gotten to a stable point we will then be >>> able to > look at resources and determine if BBOS is still a valuable >> platform >> to > support and if we can port BBOS to the new structures. > > Hope that makes sense. > > Sent from my BlackBerry Z10 smartphone. > From: Anis KADRI > Sent: Monday, March 18, 2013 1:00 PM > To: dev@cordova.apache.org > Reply To: dev@cordova.apache.org > Subject: Re: archiving older platforms > > > s/QR/Qt > > > On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer >> > wrote: > >> +1 Bada/webOS/QR >> >> echoing Michael's point, I'd like to see usage stats on the >> older BB >> platforms. BB10 should absolutely be the focus, but If they are >>> currently >> being used, mothballing may be premature. Revisiting the issues > regularly, >> and making one based on usage stats makes the most sense to me. >> >> >>
request focus
Hi all, We have an android application mixing native views and a CordovaWebView. The problem is the CordovaWebView request the focus when launching the application even in our case it should not be the view selected by default. Unfortunately there is no easy way to override this behavior because inside CordovaWebView constructors a call to a private method setup is done where the focus is requested by calling requestFocusFromTouch which is also final. I would like to submit a pull request for at least change the visibility of setup to protected in order to override this behavior. How does it sound? Did I miss something about why setup is private? BR Denis
Re: Platform-level command line scripts ;)
I knew you'd bring that up! We'll talk more tmrw. On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI wrote: > …or you can have functions do discrete actions like so: > > https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=bin/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6;hb=HEAD > > …instead of creating more inodes. > > > On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: > >> > You could make more scripts as helper scripts, but I still think that it >> > will be confusing if a user types "ls" and sees a large number of >> scripts, >> > having to guess what each of them does. >> >> Put them in a subdir called ./lib and be done w/ it. >> >> >> > I don't think having more scripts will make it more likely that the >> scripts >> > will be consistent across platforms. >> >> Ah, but having smaller responsibilities for a module of code makes it >> more testable in discreet form making it easier to confirm said >> suspicions. >>
Re: Platform-level command line scripts ;)
…or you can have functions do discrete actions like so: https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=bin/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6;hb=HEAD …instead of creating more inodes. On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: > > You could make more scripts as helper scripts, but I still think that it > > will be confusing if a user types "ls" and sees a large number of > scripts, > > having to guess what each of them does. > > Put them in a subdir called ./lib and be done w/ it. > > > > I don't think having more scripts will make it more likely that the > scripts > > will be consistent across platforms. > > Ah, but having smaller responsibilities for a module of code makes it > more testable in discreet form making it easier to confirm said > suspicions. >
Re: Platform-level command line scripts ;)
> You could make more scripts as helper scripts, but I still think that it > will be confusing if a user types "ls" and sees a large number of scripts, > having to guess what each of them does. Put them in a subdir called ./lib and be done w/ it. > I don't think having more scripts will make it more likely that the scripts > will be consistent across platforms. Ah, but having smaller responsibilities for a module of code makes it more testable in discreet form making it easier to confirm said suspicions.
Re: Platform-level command line scripts ;)
On Thu, Mar 21, 2013 at 6:51 PM, Filip Maj wrote: > It looks like we are split between Reductionist (four commands and/or less > commands) and.. The opposite.. Of reductionists? Antireductionist? > > Two points I think supporting the antireductionist argument: > > 1. number of scripts being an issue because of possible bug repetition > across scripts is put to bed by refactoring common functionality into > sub-scripts. > You could make more scripts as helper scripts, but I still think that it will be confusing if a user types "ls" and sees a large number of scripts, having to guess what each of them does. Having fewer scripts that you can --help on would be more discoverable. Having extra helper scripts that are not meant to be run directly by users would make discoverability even worse (I want to package, so do I run build-release first? do I need to run build-clean first? what about build-helpers?) I don't think having more scripts will make it more likely that the scripts will be consistent across platforms. E.g. build-release and build-debug vs. build --release build --debug. In the end, there's the same number of discrete operations that we must make consistent. > 2. more "generic" scripts have been problematic before because of > complicated workflows for some of them (like Anis points out for `run`) > and unstandardized defaults across platforms. I saw this problem at the > hack night last night, where people were confused as to the behavior of > `emulate` (does it always start a new emulator? Does it load my app onto > the emulator too?). > I don't think standardizing the commands is made easier / harder by the # of scripts. > > We have all agreed on the default implementation for all of these scripts, > however we split them out, to be: error out. > > Additionally and to Brian's point, more complex workflows can be built up > by using the baseline scripts we are trying to define here. Nothing > stopping us from composing a new `debug` script (or remember `BOOM` in > cordova-android?) once we have the baseline functionality sorted. > > It comes down to two commands currently in contention: > > 1. `build`. It's either split this up into `build-debug` and > `build-release` or `build --debug` and `build --release` with debug being > default. > 2. `run`. We are actually aiming to combine the existing `debug` and > `emulate` commands into this one new `run` one, which I think actually > exacerbates the problem we are trying to solve here. > > Should we start a separate vote thread? > > On 3/21/13 12:32 PM, "Brian LeRoux" wrote: > > >Ya tend to agree w/ the workflows you describe Jesse. Not at the > >exlusion of discreet scripts however. We probably should have small > >focused scripts and then compose the workflow scripts from them. > >(Making it easier to test and compose new scripts and tooling.) > > > > > > > >On Thu, Mar 21, 2013 at 12:07 AM, Jesse wrote: > >> renaming stuff is easy. > >> > >> Does it make sense to log without running? or does log also launch? > >>where? > >> Sounds to me like logging is an option attached to a run command. > >> What is the point of cleaning if you're not going to build right after? > >> trying to free up hard drive space? anal much? or is clean just a build > >> option? > >> > >> The current state of WP7+WP8 > >> > >> Every WP7 and WP8 cordova project that you create with the create > >>script, > >> or with the template has a debug and an emulate command. > >> debug: builds and runs on the attached device. > >> emulate : builds and runs on the first emulator, starting it if it was > >>not > >> already running > >> > >> > >> > >> > >> @purplecabbage > >> risingj.com > >> > >> > >> On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes > >>wrote: > >> > >>> I liked the idea you mentioned earlier with having one wrapper script, > >>> that way there is one entry point for the given commands for the needed > >>> functionality. Then it doesn't matter what underlying scripts actually > >>>do > >>> the work. > >>> > >>> Then our only focus would be on the commands and not so much the name > >>>of > >>> the scripts. > >>> > >>> > >>> On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve > >>> wrote: > >>> > >>> > I really like Anis's suggestion of just four scripts. What's the > >>> motivation > >>> > for having many scripts? Having fewer will dramatically reduce copy & > >>> paste > >>> > bugs. It will also aid discoverability (since you'll get --help > >>>instead > >>> of > >>> > just "ls" and infer from the name what they do). > >>> > > >>> > > >>> > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: > >>> > > >>> > > Ya ya ya we're all on agreement on this specific issue. The > >>>underlying > >>> > > platform scripts can be used regardless of whether you're using > >>> > > cordova-cli or not. > >>> > > > >>> > > On 3/20/13 3:51 PM, "Anis KADRI" wrote: > >>> > > > >>> > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes > > >>> > wrote: > >>> > > > > >>> > > >> I know th
Re: Platform-level command line scripts
Who's four-command proposal is it? Anis' or Andrew's? On 3/21/13 3:14 PM, "Brian LeRoux" wrote: >I think we can have our cake and eat it too. We should have four high >level commands. Those commands can shell to lower level discreetly >testable commands. The end user will never know the difference. The >developers win the tight abstraction we seek. > >Make sense? > >On Thu, Mar 21, 2013 at 2:55 PM, Anis KADRI wrote: >> On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks >>wrote: >> >>> +1 Fil's outlined design. >>> >>> I'm still not convinced of what Anis and Andrew are in favour of. >>>Having >>> each script do more will make it more difficult for common results >>>across >>> all platforms. >>> >>> I really like Anis's suggestion of just four scripts. What's the >>>motivation >>> > for having many scripts? Having fewer will dramatically reduce copy & >>> paste >>> > bugs. It will also aid discoverability (since you'll get --help >>>instead >>> of >>> > just "ls" and infer from the name what they do). >>> >>> >>> The motivation for having many scripts is that there is a single entry >>> point for a single action. Each action is discrete. Either a platform >>> supports `deploy-emulator` or doesn't. If we have a single `run` >>> entry-point, it becomes confusing whether a platform supports all >>> requirements of the `run` action. >>> >>> I feel the code repetition is also a weak argument. We are defining >>> entry-point scripts. You can refactor out the common routines (e.g. >>>build) >>> into a helper script that can be invoked by multiple scripts. As far >>>as I >>> know, this is possible in bash, batch, and Windows Script Hosting. >>> >> >> I guess this topic will need a vote to follow the Apache Way. We've been >> talking about/implementing/changing these scripts for a long time and we >> can't seem to come to a complete agreement. >> >> >>> >>> ripple should be a separate option and not a separate command in my >>> > opinion. To simplify things and if everyone agrees we can ignore the >>> `run` >>> > command flow above and launch ripple by default and ask users to >>>specify >>> > options if they want to deploy and run to a particular >>>device/emulator. >>> >>> >>> I feel Ripple has no place in the platform-specific scripts. I love >>>Ripple, >>> but Ripple belongs is a higher-level tool such as Cordova CLI. The >>> platform-specific scripts are meant to deal with platform-specific >>> functions. >>> >> >> I don't have a strong opinion on this. So I could agree with you that >>this >> Ripple could be a higher-level tool. >> >> >>> >>> Michael >>> >>> On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes >>>wrote: >>> >>> > I liked the idea you mentioned earlier with having one wrapper >>>script, >>> > that way there is one entry point for the given commands for the >>>needed >>> > functionality. Then it doesn't matter what underlying scripts >>>actually do >>> > the work. >>> > >>> > Then our only focus would be on the commands and not so much the >>>name of >>> > the scripts. >>> > >>> > >>> > On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve >>> > wrote: >>> > >>> > > I really like Anis's suggestion of just four scripts. What's the >>> > motivation >>> > > for having many scripts? Having fewer will dramatically reduce >>>copy & >>> > paste >>> > > bugs. It will also aid discoverability (since you'll get --help >>>instead >>> > of >>> > > just "ls" and infer from the name what they do). >>> > > >>> > > >>> > > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: >>> > > >>> > > > Ya ya ya we're all on agreement on this specific issue. The >>> underlying >>> > > > platform scripts can be used regardless of whether you're using >>> > > > cordova-cli or not. >>> > > > >>> > > > On 3/20/13 3:51 PM, "Anis KADRI" wrote: >>> > > > >>> > > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes >>> >>> > > wrote: >>> > > > > >>> > > > >> I know that sounds >>> > > > >> like a lot >>> > > > >> of scripts but we're building them for the cordova-cli to use, >>> so i >>> > > > >>like >>> > > > >> the idea of breaking >>> > > > >> them out so each script does a *very specific* task with as >>> > > > >>little-to-no >>> > > > >> >>> > > > > >>> > > > >No we're not. cordova-cli is a cool tool that people can use >>>but it >>> > > should >>> > > > >not be the only way of building Cordova apps in my opinion. >>> > > > >>> > > > >>> > > >>> > >>>
Re: Platform-level command line scripts
Yes... Why Not... That's part of the fun ... Isn't it?? [?] On Thu, Mar 21, 2013 at 6:14 PM, Brian LeRoux wrote: > I think we can have our cake and eat it too. We should have four high > level commands. Those commands can shell to lower level discreetly > testable commands. The end user will never know the difference. The > developers win the tight abstraction we seek. > > Make sense? > > On Thu, Mar 21, 2013 at 2:55 PM, Anis KADRI wrote: > > On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks < > mich...@michaelbrooks.ca>wrote: > > > >> +1 Fil's outlined design. > >> > >> I'm still not convinced of what Anis and Andrew are in favour of. Having > >> each script do more will make it more difficult for common results > across > >> all platforms. > >> > >> I really like Anis's suggestion of just four scripts. What's the > motivation > >> > for having many scripts? Having fewer will dramatically reduce copy & > >> paste > >> > bugs. It will also aid discoverability (since you'll get --help > instead > >> of > >> > just "ls" and infer from the name what they do). > >> > >> > >> The motivation for having many scripts is that there is a single entry > >> point for a single action. Each action is discrete. Either a platform > >> supports `deploy-emulator` or doesn't. If we have a single `run` > >> entry-point, it becomes confusing whether a platform supports all > >> requirements of the `run` action. > >> > >> I feel the code repetition is also a weak argument. We are defining > >> entry-point scripts. You can refactor out the common routines (e.g. > build) > >> into a helper script that can be invoked by multiple scripts. As far as > I > >> know, this is possible in bash, batch, and Windows Script Hosting. > >> > > > > I guess this topic will need a vote to follow the Apache Way. We've been > > talking about/implementing/changing these scripts for a long time and we > > can't seem to come to a complete agreement. > > > > > >> > >> ripple should be a separate option and not a separate command in my > >> > opinion. To simplify things and if everyone agrees we can ignore the > >> `run` > >> > command flow above and launch ripple by default and ask users to > specify > >> > options if they want to deploy and run to a particular > device/emulator. > >> > >> > >> I feel Ripple has no place in the platform-specific scripts. I love > Ripple, > >> but Ripple belongs is a higher-level tool such as Cordova CLI. The > >> platform-specific scripts are meant to deal with platform-specific > >> functions. > >> > > > > I don't have a strong opinion on this. So I could agree with you that > this > > Ripple could be a higher-level tool. > > > > > >> > >> Michael > >> > >> On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes > wrote: > >> > >> > I liked the idea you mentioned earlier with having one wrapper script, > >> > that way there is one entry point for the given commands for the > needed > >> > functionality. Then it doesn't matter what underlying scripts > actually do > >> > the work. > >> > > >> > Then our only focus would be on the commands and not so much the name > of > >> > the scripts. > >> > > >> > > >> > On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve > >> > wrote: > >> > > >> > > I really like Anis's suggestion of just four scripts. What's the > >> > motivation > >> > > for having many scripts? Having fewer will dramatically reduce copy > & > >> > paste > >> > > bugs. It will also aid discoverability (since you'll get --help > instead > >> > of > >> > > just "ls" and infer from the name what they do). > >> > > > >> > > > >> > > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: > >> > > > >> > > > Ya ya ya we're all on agreement on this specific issue. The > >> underlying > >> > > > platform scripts can be used regardless of whether you're using > >> > > > cordova-cli or not. > >> > > > > >> > > > On 3/20/13 3:51 PM, "Anis KADRI" wrote: > >> > > > > >> > > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes < > benn.ma...@gmail.com> > >> > > wrote: > >> > > > > > >> > > > >> I know that sounds > >> > > > >> like a lot > >> > > > >> of scripts but we're building them for the cordova-cli to use, > >> so i > >> > > > >>like > >> > > > >> the idea of breaking > >> > > > >> them out so each script does a *very specific* task with as > >> > > > >>little-to-no > >> > > > >> > >> > > > > > >> > > > >No we're not. cordova-cli is a cool tool that people can use but > it > >> > > should > >> > > > >not be the only way of building Cordova apps in my opinion. > >> > > > > >> > > > > >> > > > >> > > >> >
Re: Platform-level command line scripts ;)
It looks like we are split between Reductionist (four commands and/or less commands) and.. The opposite.. Of reductionists? Antireductionist? Two points I think supporting the antireductionist argument: 1. number of scripts being an issue because of possible bug repetition across scripts is put to bed by refactoring common functionality into sub-scripts. 2. more "generic" scripts have been problematic before because of complicated workflows for some of them (like Anis points out for `run`) and unstandardized defaults across platforms. I saw this problem at the hack night last night, where people were confused as to the behavior of `emulate` (does it always start a new emulator? Does it load my app onto the emulator too?). We have all agreed on the default implementation for all of these scripts, however we split them out, to be: error out. Additionally and to Brian's point, more complex workflows can be built up by using the baseline scripts we are trying to define here. Nothing stopping us from composing a new `debug` script (or remember `BOOM` in cordova-android?) once we have the baseline functionality sorted. It comes down to two commands currently in contention: 1. `build`. It's either split this up into `build-debug` and `build-release` or `build --debug` and `build --release` with debug being default. 2. `run`. We are actually aiming to combine the existing `debug` and `emulate` commands into this one new `run` one, which I think actually exacerbates the problem we are trying to solve here. Should we start a separate vote thread? On 3/21/13 12:32 PM, "Brian LeRoux" wrote: >Ya tend to agree w/ the workflows you describe Jesse. Not at the >exlusion of discreet scripts however. We probably should have small >focused scripts and then compose the workflow scripts from them. >(Making it easier to test and compose new scripts and tooling.) > > > >On Thu, Mar 21, 2013 at 12:07 AM, Jesse wrote: >> renaming stuff is easy. >> >> Does it make sense to log without running? or does log also launch? >>where? >> Sounds to me like logging is an option attached to a run command. >> What is the point of cleaning if you're not going to build right after? >> trying to free up hard drive space? anal much? or is clean just a build >> option? >> >> The current state of WP7+WP8 >> >> Every WP7 and WP8 cordova project that you create with the create >>script, >> or with the template has a debug and an emulate command. >> debug: builds and runs on the attached device. >> emulate : builds and runs on the first emulator, starting it if it was >>not >> already running >> >> >> >> >> @purplecabbage >> risingj.com >> >> >> On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes >>wrote: >> >>> I liked the idea you mentioned earlier with having one wrapper script, >>> that way there is one entry point for the given commands for the needed >>> functionality. Then it doesn't matter what underlying scripts actually >>>do >>> the work. >>> >>> Then our only focus would be on the commands and not so much the name >>>of >>> the scripts. >>> >>> >>> On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve >>> wrote: >>> >>> > I really like Anis's suggestion of just four scripts. What's the >>> motivation >>> > for having many scripts? Having fewer will dramatically reduce copy & >>> paste >>> > bugs. It will also aid discoverability (since you'll get --help >>>instead >>> of >>> > just "ls" and infer from the name what they do). >>> > >>> > >>> > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: >>> > >>> > > Ya ya ya we're all on agreement on this specific issue. The >>>underlying >>> > > platform scripts can be used regardless of whether you're using >>> > > cordova-cli or not. >>> > > >>> > > On 3/20/13 3:51 PM, "Anis KADRI" wrote: >>> > > >>> > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes >>> > wrote: >>> > > > >>> > > >> I know that sounds >>> > > >> like a lot >>> > > >> of scripts but we're building them for the cordova-cli to use, >>>so i >>> > > >>like >>> > > >> the idea of breaking >>> > > >> them out so each script does a *very specific* task with as >>> > > >>little-to-no >>> > > >> >>> > > > >>> > > >No we're not. cordova-cli is a cool tool that people can use but >>>it >>> > should >>> > > >not be the only way of building Cordova apps in my opinion. >>> > > >>> > > >>> > >>>
Re: Platform-level command line scripts
+1 On 22/03/2013, at 9:14 AM, Brian LeRoux wrote: > I think we can have our cake and eat it too. We should have four high > level commands. Those commands can shell to lower level discreetly > testable commands. The end user will never know the difference. The > developers win the tight abstraction we seek. > > Make sense? > > On Thu, Mar 21, 2013 at 2:55 PM, Anis KADRI wrote: >> On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks >> wrote: >> >>> +1 Fil's outlined design. >>> >>> I'm still not convinced of what Anis and Andrew are in favour of. Having >>> each script do more will make it more difficult for common results across >>> all platforms. >>> >>> I really like Anis's suggestion of just four scripts. What's the motivation for having many scripts? Having fewer will dramatically reduce copy & >>> paste bugs. It will also aid discoverability (since you'll get --help instead >>> of just "ls" and infer from the name what they do). >>> >>> >>> The motivation for having many scripts is that there is a single entry >>> point for a single action. Each action is discrete. Either a platform >>> supports `deploy-emulator` or doesn't. If we have a single `run` >>> entry-point, it becomes confusing whether a platform supports all >>> requirements of the `run` action. >>> >>> I feel the code repetition is also a weak argument. We are defining >>> entry-point scripts. You can refactor out the common routines (e.g. build) >>> into a helper script that can be invoked by multiple scripts. As far as I >>> know, this is possible in bash, batch, and Windows Script Hosting. >>> >> >> I guess this topic will need a vote to follow the Apache Way. We've been >> talking about/implementing/changing these scripts for a long time and we >> can't seem to come to a complete agreement. >> >> >>> >>> ripple should be a separate option and not a separate command in my opinion. To simplify things and if everyone agrees we can ignore the >>> `run` command flow above and launch ripple by default and ask users to specify options if they want to deploy and run to a particular device/emulator. >>> >>> >>> I feel Ripple has no place in the platform-specific scripts. I love Ripple, >>> but Ripple belongs is a higher-level tool such as Cordova CLI. The >>> platform-specific scripts are meant to deal with platform-specific >>> functions. >>> >> >> I don't have a strong opinion on this. So I could agree with you that this >> Ripple could be a higher-level tool. >> >> >>> >>> Michael >>> >>> On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes wrote: >>> I liked the idea you mentioned earlier with having one wrapper script, that way there is one entry point for the given commands for the needed functionality. Then it doesn't matter what underlying scripts actually do the work. Then our only focus would be on the commands and not so much the name of the scripts. On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve wrote: > I really like Anis's suggestion of just four scripts. What's the motivation > for having many scripts? Having fewer will dramatically reduce copy & paste > bugs. It will also aid discoverability (since you'll get --help instead of > just "ls" and infer from the name what they do). > > > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: > >> Ya ya ya we're all on agreement on this specific issue. The >>> underlying >> platform scripts can be used regardless of whether you're using >> cordova-cli or not. >> >> On 3/20/13 3:51 PM, "Anis KADRI" wrote: >> >>> On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes > wrote: >>> I know that sounds like a lot of scripts but we're building them for the cordova-cli to use, >>> so i like the idea of breaking them out so each script does a *very specific* task with as little-to-no >>> >>> No we're not. cordova-cli is a cool tool that people can use but it > should >>> not be the only way of building Cordova apps in my opinion. >> >> > >>>
Re: Pull requests done
My hero. On 22/03/2013, at 8:36 AM, Shazron wrote: > Yup :) > > > On Thu, Mar 21, 2013 at 2:20 PM, Tommy-Carlos Williams > wrote: > >> Shazron, >> >> So do your FileTransfer tests resolve CB-2687 [1] ? >> >> [1] https://issues.apache.org/jira/browse/CB-2687 >> >> >> On 22/03/2013, at 3:22 AM, Shazron wrote: >> >>> Thanks Andrew! >>> I've got new mobile-spec FileTransfer tests in for the new basic auth >>> upload/download plus the corresponding new deployed >>> cordova-filetransfer.jitsu.com script. There might be failures on some >>> platforms for these 2 new tests (WP7 comes to mind since it doesn't >> support >>> window.btoa in JavaScript) >>> >>> I'd like to get some doc changes in for today (iOS / OS X) but I suppose >> we >>> can get the release train running... >>> >>> >>> On Thu, Mar 21, 2013 at 2:00 AM, Xavier wrote: >>> > Noticed a cordova-js pull request for Windows If you are referring to "Windows build (CB-1667 and CB-2588)" [1], I'd like to clarify that it is about Windows as a development platform [2][3], not as a cordova platform [1] https://github.com/apache/cordova-js/pull/14 [2] https://issues.apache.org/jira/browse/CB-1667 [3] https://issues.apache.org/jira/browse/CB-2588 -Xavier >> >>
Re: archiving older platforms
Attic seems like more work than outright neglect. Might be for conceptual purity we want to move Bada there but I could see Qt and webOS rising from their slumber. On Thu, Mar 21, 2013 at 3:30 PM, Anis KADRI wrote: > and no apache attic [1] ? > > [1] http://attic.apache.org/ > > > On Thu, Mar 21, 2013 at 3:28 PM, Brian LeRoux wrote: > >> This means we're going to leave Bada, Qt, webOS at their latest tags, >> and not dist. (Code still accessible, etc.) >> >> We'll continue as normal for BB, for now. >> >> >> >> On Thu, Mar 21, 2013 at 3:09 PM, Gord Tanner wrote: >> > I am confused, who are the stewards and what platforms are being >> stewarded? >> > >> > Sent from my iPhone >> > >> > On 2013-03-21, at 6:00 PM, Filip Maj wrote: >> > >> >> +1 >> >> >> >> On 3/21/13 2:12 PM, "Shazron" wrote: >> >> >> >>> +1 >> >>> >> >>> >> >>> On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny >> wrote: >> >>> >> +1 >> >> >> On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: >> >> > Ok, I think we have agreement that we'll put these guys on hold until >> > they find a steward. This means: >> > >> > - we won't be taggin them further >> > - we won't be including them in a release >> > >> > This does not mean: >> > >> > - deletion or archiving or attic for the src >> > >> > (Think of it as a pause button!) >> > >> > Agree/disagree? >> > >> > On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve > > >> > wrote: >> >> If there are no fixes going into these platforms, then there is no >> > benefit >> >> in their users updating them to newer versions of Cordova. >> >> >> >> There's going to be more refactoring required when moving plugins to >> > their >> >> own repos. We'll really need owners for all platforms that will make >> the >> >> transition, or else we won't have any way to test that the >> refactoring >> >> hasn't broken a platform. On specific example is that blackberry's >> JS >> > repo >> >> is really 4-in-1 currently, and our plugin spec doesn't have support >> for >> >> this. They will need to be split out into 4 separate platforms, at >> least >> > as >> >> far as the JS is concerned. >> >> >> >> So... I guess my +1 is just for any platform that doesn't have a >> someone >> >> willing to focus on it. E.g. I'm fine with keeping WebOS around if >> Markus >> >> wants to do the work to support it through this transition. >> >> >> >> >> >> On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis >> >> > wrote: >> >> >> >>> >> >>> We will try to provide relevant stats on platform adoption as we >> are >> > able. >> >>> I am anxiously awaiting that information myself. ;) >> >>> >> >>> While lacking this information, I still feel that BBOS will be >> with us >> > for >> >>> a deal of time, particularly in the enterprise where we are seeing >> a >> >>> significant trend towards Cordova/PhoneGap/WebWorks as the primary >> > platform >> >>> of choice for apps. This is, frustratingly, a difficult market to >> get >> >>> adequate metrics out of, as they will typically not use PhoneGap >> Build >> > IMO, >> >>> and they don't deploy to commercial application stores. A bit of a >> black >> >>> box, but our enterprise support teams continually support the >> notion >> > that >> >>> enterprise looks at HTML5 apps first. >> >>> >> >>> In this regard, we would like to see support for BBOS be >> maintained in >> > the >> >>> short term. Our team is focused on bringing up BlackBerry 10 built >> on >> >>> Cordova, and once that has gotten to a stable point we will then be >> > able to >> >>> look at resources and determine if BBOS is still a valuable >> platform >> to >> >>> support and if we can port BBOS to the new structures. >> >>> >> >>> Hope that makes sense. >> >>> >> >>> Sent from my BlackBerry Z10 smartphone. >> >>> From: Anis KADRI >> >>> Sent: Monday, March 18, 2013 1:00 PM >> >>> To: dev@cordova.apache.org >> >>> Reply To: dev@cordova.apache.org >> >>> Subject: Re: archiving older platforms >> >>> >> >>> >> >>> s/QR/Qt >> >>> >> >>> >> >>> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer >> > wrote: >> >>> >> +1 Bada/webOS/QR >> >> echoing Michael's point, I'd like to see usage stats on the >> older BB >> platforms. BB10 should absolutely be the focus, but If they are >> > currently >> being used, mothballing may be premature. Revisiting the issues >> >>> regularly, >> and making one based on usage stats makes the most sense to me. >> >> >> On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj >> wrote: >> >>
Re: archiving older platforms
and no apache attic [1] ? [1] http://attic.apache.org/ On Thu, Mar 21, 2013 at 3:28 PM, Brian LeRoux wrote: > This means we're going to leave Bada, Qt, webOS at their latest tags, > and not dist. (Code still accessible, etc.) > > We'll continue as normal for BB, for now. > > > > On Thu, Mar 21, 2013 at 3:09 PM, Gord Tanner wrote: > > I am confused, who are the stewards and what platforms are being > stewarded? > > > > Sent from my iPhone > > > > On 2013-03-21, at 6:00 PM, Filip Maj wrote: > > > >> +1 > >> > >> On 3/21/13 2:12 PM, "Shazron" wrote: > >> > >>> +1 > >>> > >>> > >>> On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny > wrote: > >>> > +1 > > > On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: > > > Ok, I think we have agreement that we'll put these guys on hold until > > they find a steward. This means: > > > > - we won't be taggin them further > > - we won't be including them in a release > > > > This does not mean: > > > > - deletion or archiving or attic for the src > > > > (Think of it as a pause button!) > > > > Agree/disagree? > > > > On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve > > > wrote: > >> If there are no fixes going into these platforms, then there is no > > benefit > >> in their users updating them to newer versions of Cordova. > >> > >> There's going to be more refactoring required when moving plugins to > > their > >> own repos. We'll really need owners for all platforms that will make > the > >> transition, or else we won't have any way to test that the > refactoring > >> hasn't broken a platform. On specific example is that blackberry's > JS > > repo > >> is really 4-in-1 currently, and our plugin spec doesn't have support > for > >> this. They will need to be split out into 4 separate platforms, at > least > > as > >> far as the JS is concerned. > >> > >> So... I guess my +1 is just for any platform that doesn't have a > someone > >> willing to focus on it. E.g. I'm fine with keeping WebOS around if > Markus > >> wants to do the work to support it through this transition. > >> > >> > >> On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis > > > wrote: > >> > >>> > >>> We will try to provide relevant stats on platform adoption as we > are > > able. > >>> I am anxiously awaiting that information myself. ;) > >>> > >>> While lacking this information, I still feel that BBOS will be > with us > > for > >>> a deal of time, particularly in the enterprise where we are seeing > a > >>> significant trend towards Cordova/PhoneGap/WebWorks as the primary > > platform > >>> of choice for apps. This is, frustratingly, a difficult market to > get > >>> adequate metrics out of, as they will typically not use PhoneGap > Build > > IMO, > >>> and they don't deploy to commercial application stores. A bit of a > black > >>> box, but our enterprise support teams continually support the > notion > > that > >>> enterprise looks at HTML5 apps first. > >>> > >>> In this regard, we would like to see support for BBOS be > maintained in > > the > >>> short term. Our team is focused on bringing up BlackBerry 10 built > on > >>> Cordova, and once that has gotten to a stable point we will then be > > able to > >>> look at resources and determine if BBOS is still a valuable > platform > to > >>> support and if we can port BBOS to the new structures. > >>> > >>> Hope that makes sense. > >>> > >>> Sent from my BlackBerry Z10 smartphone. > >>> From: Anis KADRI > >>> Sent: Monday, March 18, 2013 1:00 PM > >>> To: dev@cordova.apache.org > >>> Reply To: dev@cordova.apache.org > >>> Subject: Re: archiving older platforms > >>> > >>> > >>> s/QR/Qt > >>> > >>> > >>> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer > wrote: > >>> > +1 Bada/webOS/QR > > echoing Michael's point, I'd like to see usage stats on the > older BB > platforms. BB10 should absolutely be the focus, but If they are > > currently > being used, mothballing may be premature. Revisiting the issues > >>> regularly, > and making one based on usage stats makes the most sense to me. > > > On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj > wrote: > > > +1 all of them, Java and Air implementations of BlackBerry as > well. > > > > For the older implementations of BlackBerry, nothing is > stopping > > anyone > > from using that code. The fact is that Java and Air-related > fixes > > have > not > > been going in regularly. The implementations
Re: archiving older platforms
This means we're going to leave Bada, Qt, webOS at their latest tags, and not dist. (Code still accessible, etc.) We'll continue as normal for BB, for now. On Thu, Mar 21, 2013 at 3:09 PM, Gord Tanner wrote: > I am confused, who are the stewards and what platforms are being stewarded? > > Sent from my iPhone > > On 2013-03-21, at 6:00 PM, Filip Maj wrote: > >> +1 >> >> On 3/21/13 2:12 PM, "Shazron" wrote: >> >>> +1 >>> >>> >>> On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny wrote: >>> +1 On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: > Ok, I think we have agreement that we'll put these guys on hold until > they find a steward. This means: > > - we won't be taggin them further > - we won't be including them in a release > > This does not mean: > > - deletion or archiving or attic for the src > > (Think of it as a pause button!) > > Agree/disagree? > > On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve > wrote: >> If there are no fixes going into these platforms, then there is no > benefit >> in their users updating them to newer versions of Cordova. >> >> There's going to be more refactoring required when moving plugins to > their >> own repos. We'll really need owners for all platforms that will make the >> transition, or else we won't have any way to test that the refactoring >> hasn't broken a platform. On specific example is that blackberry's JS > repo >> is really 4-in-1 currently, and our plugin spec doesn't have support for >> this. They will need to be split out into 4 separate platforms, at least > as >> far as the JS is concerned. >> >> So... I guess my +1 is just for any platform that doesn't have a someone >> willing to focus on it. E.g. I'm fine with keeping WebOS around if Markus >> wants to do the work to support it through this transition. >> >> >> On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis > wrote: >> >>> >>> We will try to provide relevant stats on platform adoption as we are > able. >>> I am anxiously awaiting that information myself. ;) >>> >>> While lacking this information, I still feel that BBOS will be with us > for >>> a deal of time, particularly in the enterprise where we are seeing a >>> significant trend towards Cordova/PhoneGap/WebWorks as the primary > platform >>> of choice for apps. This is, frustratingly, a difficult market to get >>> adequate metrics out of, as they will typically not use PhoneGap Build > IMO, >>> and they don't deploy to commercial application stores. A bit of a black >>> box, but our enterprise support teams continually support the notion > that >>> enterprise looks at HTML5 apps first. >>> >>> In this regard, we would like to see support for BBOS be maintained in > the >>> short term. Our team is focused on bringing up BlackBerry 10 built on >>> Cordova, and once that has gotten to a stable point we will then be > able to >>> look at resources and determine if BBOS is still a valuable platform to >>> support and if we can port BBOS to the new structures. >>> >>> Hope that makes sense. >>> >>> Sent from my BlackBerry Z10 smartphone. >>> From: Anis KADRI >>> Sent: Monday, March 18, 2013 1:00 PM >>> To: dev@cordova.apache.org >>> Reply To: dev@cordova.apache.org >>> Subject: Re: archiving older platforms >>> >>> >>> s/QR/Qt >>> >>> >>> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer >>> wrote: >>> +1 Bada/webOS/QR echoing Michael's point, I'd like to see usage stats on the older BB platforms. BB10 should absolutely be the focus, but If they are > currently being used, mothballing may be premature. Revisiting the issues >>> regularly, and making one based on usage stats makes the most sense to me. On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj wrote: > +1 all of them, Java and Air implementations of BlackBerry as well. > > For the older implementations of BlackBerry, nothing is stopping > anyone > from using that code. The fact is that Java and Air-related fixes > have not > been going in regularly. The implementations are stable enough that > drawing a line in the sand and saying no more active support for the older > BB SDKs is acceptable in my opinion. > > On 3/17/13 11:44 AM, "Michael Brooks" >>> wrote: > >>> >>> As far as bb 6 and 7, I am sure the majority of devices out there >>> are >>> BB 6 >>> and 7. BB10 just c
Re: cordova-cli and plugman overview march 22nd 9am Pacific
I'll be likely doing it from home. Some of the other committers too. It's open to the public, essentially, so setting a limit of 10 I think is unreasonable. On 3/21/13 3:18 PM, "Braden Shepherdson" wrote: >I think it's 10. Will we have that many different rooms/laptops? All the >Googlers will be in one room, hopefully most of the Apache SF folks can do >the same. > > >On Thu, Mar 21, 2013 at 6:09 PM, Filip Maj wrote: > >> I am looking into setting up a connect room as hangouts only support 20 >> people I believe (unless I'm wrong) >> >> Will be posting meeting details shortly >> >>
Re: cordova-cli and plugman overview march 22nd 9am Pacific
http://my.adobeconnect.com/cordova I'll aim to start around 905am. Connect supports like 300 people. You'll need flash (sorry) and probably have to use firefox (sorry). On 3/21/13 3:09 PM, "Filip Maj" wrote: >I am looking into setting up a connect room as hangouts only support 20 >people I believe (unless I'm wrong) > >Will be posting meeting details shortly >
Re: cordova-cli and plugman overview march 22nd 9am Pacific
I think it's 10. Will we have that many different rooms/laptops? All the Googlers will be in one room, hopefully most of the Apache SF folks can do the same. On Thu, Mar 21, 2013 at 6:09 PM, Filip Maj wrote: > I am looking into setting up a connect room as hangouts only support 20 > people I believe (unless I'm wrong) > > Will be posting meeting details shortly > >
Re: Platform-level command line scripts
I think we can have our cake and eat it too. We should have four high level commands. Those commands can shell to lower level discreetly testable commands. The end user will never know the difference. The developers win the tight abstraction we seek. Make sense? On Thu, Mar 21, 2013 at 2:55 PM, Anis KADRI wrote: > On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks > wrote: > >> +1 Fil's outlined design. >> >> I'm still not convinced of what Anis and Andrew are in favour of. Having >> each script do more will make it more difficult for common results across >> all platforms. >> >> I really like Anis's suggestion of just four scripts. What's the motivation >> > for having many scripts? Having fewer will dramatically reduce copy & >> paste >> > bugs. It will also aid discoverability (since you'll get --help instead >> of >> > just "ls" and infer from the name what they do). >> >> >> The motivation for having many scripts is that there is a single entry >> point for a single action. Each action is discrete. Either a platform >> supports `deploy-emulator` or doesn't. If we have a single `run` >> entry-point, it becomes confusing whether a platform supports all >> requirements of the `run` action. >> >> I feel the code repetition is also a weak argument. We are defining >> entry-point scripts. You can refactor out the common routines (e.g. build) >> into a helper script that can be invoked by multiple scripts. As far as I >> know, this is possible in bash, batch, and Windows Script Hosting. >> > > I guess this topic will need a vote to follow the Apache Way. We've been > talking about/implementing/changing these scripts for a long time and we > can't seem to come to a complete agreement. > > >> >> ripple should be a separate option and not a separate command in my >> > opinion. To simplify things and if everyone agrees we can ignore the >> `run` >> > command flow above and launch ripple by default and ask users to specify >> > options if they want to deploy and run to a particular device/emulator. >> >> >> I feel Ripple has no place in the platform-specific scripts. I love Ripple, >> but Ripple belongs is a higher-level tool such as Cordova CLI. The >> platform-specific scripts are meant to deal with platform-specific >> functions. >> > > I don't have a strong opinion on this. So I could agree with you that this > Ripple could be a higher-level tool. > > >> >> Michael >> >> On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes wrote: >> >> > I liked the idea you mentioned earlier with having one wrapper script, >> > that way there is one entry point for the given commands for the needed >> > functionality. Then it doesn't matter what underlying scripts actually do >> > the work. >> > >> > Then our only focus would be on the commands and not so much the name of >> > the scripts. >> > >> > >> > On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve >> > wrote: >> > >> > > I really like Anis's suggestion of just four scripts. What's the >> > motivation >> > > for having many scripts? Having fewer will dramatically reduce copy & >> > paste >> > > bugs. It will also aid discoverability (since you'll get --help instead >> > of >> > > just "ls" and infer from the name what they do). >> > > >> > > >> > > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: >> > > >> > > > Ya ya ya we're all on agreement on this specific issue. The >> underlying >> > > > platform scripts can be used regardless of whether you're using >> > > > cordova-cli or not. >> > > > >> > > > On 3/20/13 3:51 PM, "Anis KADRI" wrote: >> > > > >> > > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes >> > > wrote: >> > > > > >> > > > >> I know that sounds >> > > > >> like a lot >> > > > >> of scripts but we're building them for the cordova-cli to use, >> so i >> > > > >>like >> > > > >> the idea of breaking >> > > > >> them out so each script does a *very specific* task with as >> > > > >>little-to-no >> > > > >> >> > > > > >> > > > >No we're not. cordova-cli is a cool tool that people can use but it >> > > should >> > > > >not be the only way of building Cordova apps in my opinion. >> > > > >> > > > >> > > >> > >>
cordova-cli and plugman overview march 22nd 9am Pacific
I am looking into setting up a connect room as hangouts only support 20 people I believe (unless I'm wrong) Will be posting meeting details shortly
Re: archiving older platforms
I am confused, who are the stewards and what platforms are being stewarded? Sent from my iPhone On 2013-03-21, at 6:00 PM, Filip Maj wrote: > +1 > > On 3/21/13 2:12 PM, "Shazron" wrote: > >> +1 >> >> >> On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny wrote: >> >>> +1 >>> >>> >>> On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: >>> Ok, I think we have agreement that we'll put these guys on hold until they find a steward. This means: - we won't be taggin them further - we won't be including them in a release This does not mean: - deletion or archiving or attic for the src (Think of it as a pause button!) Agree/disagree? On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve wrote: > If there are no fixes going into these platforms, then there is no benefit > in their users updating them to newer versions of Cordova. > > There's going to be more refactoring required when moving plugins to their > own repos. We'll really need owners for all platforms that will make >>> the > transition, or else we won't have any way to test that the >>> refactoring > hasn't broken a platform. On specific example is that blackberry's >>> JS repo > is really 4-in-1 currently, and our plugin spec doesn't have support >>> for > this. They will need to be split out into 4 separate platforms, at >>> least as > far as the JS is concerned. > > So... I guess my +1 is just for any platform that doesn't have a >>> someone > willing to focus on it. E.g. I'm fine with keeping WebOS around if >>> Markus > wants to do the work to support it through this transition. > > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis >>> wrote: > >> >> We will try to provide relevant stats on platform adoption as we >>> are able. >> I am anxiously awaiting that information myself. ;) >> >> While lacking this information, I still feel that BBOS will be >>> with us for >> a deal of time, particularly in the enterprise where we are seeing >>> a >> significant trend towards Cordova/PhoneGap/WebWorks as the primary platform >> of choice for apps. This is, frustratingly, a difficult market to >>> get >> adequate metrics out of, as they will typically not use PhoneGap >>> Build IMO, >> and they don't deploy to commercial application stores. A bit of a >>> black >> box, but our enterprise support teams continually support the >>> notion that >> enterprise looks at HTML5 apps first. >> >> In this regard, we would like to see support for BBOS be >>> maintained in the >> short term. Our team is focused on bringing up BlackBerry 10 built >>> on >> Cordova, and once that has gotten to a stable point we will then be able to >> look at resources and determine if BBOS is still a valuable >>> platform >>> to >> support and if we can port BBOS to the new structures. >> >> Hope that makes sense. >> >> Sent from my BlackBerry Z10 smartphone. >> From: Anis KADRI >> Sent: Monday, March 18, 2013 1:00 PM >> To: dev@cordova.apache.org >> Reply To: dev@cordova.apache.org >> Subject: Re: archiving older platforms >> >> >> s/QR/Qt >> >> >> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer >>> >> wrote: >> >>> +1 Bada/webOS/QR >>> >>> echoing Michael's point, I'd like to see usage stats on the >>> older BB >>> platforms. BB10 should absolutely be the focus, but If they are currently >>> being used, mothballing may be premature. Revisiting the issues >> regularly, >>> and making one based on usage stats makes the most sense to me. >>> >>> >>> On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj >>> wrote: >>> +1 all of them, Java and Air implementations of BlackBerry as >>> well. For the older implementations of BlackBerry, nothing is >>> stopping anyone from using that code. The fact is that Java and Air-related >>> fixes have >>> not been going in regularly. The implementations are stable enough >>> that drawing a line in the sand and saying no more active support >>> for >>> the >>> older BB SDKs is acceptable in my opinion. On 3/17/13 11:44 AM, "Michael Brooks" >>> >> wrote: >> >> As far as bb 6 and 7, I am sure the majority of devices out >>> there >> are >> BB 6 >> and 7. BB10 just came out so there can't be that many yet. >> Developers >> don't >> seem to be interested in those platform though and I think >>> the focus >> should >> be on BB10. > > > It would probably be more accurate to say "BlackBerry Java" >>> which >>> includes > BB 4.6/
Re: archiving older platforms
+1 On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: > Ok, I think we have agreement that we'll put these guys on hold until > they find a steward. This means: > > - we won't be taggin them further > - we won't be including them in a release > > This does not mean: > > - deletion or archiving or attic for the src > > (Think of it as a pause button!) > > Agree/disagree? > > On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve > wrote: > > If there are no fixes going into these platforms, then there is no > benefit > > in their users updating them to newer versions of Cordova. > > > > There's going to be more refactoring required when moving plugins to > their > > own repos. We'll really need owners for all platforms that will make the > > transition, or else we won't have any way to test that the refactoring > > hasn't broken a platform. On specific example is that blackberry's JS > repo > > is really 4-in-1 currently, and our plugin spec doesn't have support for > > this. They will need to be split out into 4 separate platforms, at least > as > > far as the JS is concerned. > > > > So... I guess my +1 is just for any platform that doesn't have a someone > > willing to focus on it. E.g. I'm fine with keeping WebOS around if Markus > > wants to do the work to support it through this transition. > > > > > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis > wrote: > > > >> > >> We will try to provide relevant stats on platform adoption as we are > able. > >> I am anxiously awaiting that information myself. ;) > >> > >> While lacking this information, I still feel that BBOS will be with us > for > >> a deal of time, particularly in the enterprise where we are seeing a > >> significant trend towards Cordova/PhoneGap/WebWorks as the primary > platform > >> of choice for apps. This is, frustratingly, a difficult market to get > >> adequate metrics out of, as they will typically not use PhoneGap Build > IMO, > >> and they don't deploy to commercial application stores. A bit of a black > >> box, but our enterprise support teams continually support the notion > that > >> enterprise looks at HTML5 apps first. > >> > >> In this regard, we would like to see support for BBOS be maintained in > the > >> short term. Our team is focused on bringing up BlackBerry 10 built on > >> Cordova, and once that has gotten to a stable point we will then be > able to > >> look at resources and determine if BBOS is still a valuable platform to > >> support and if we can port BBOS to the new structures. > >> > >> Hope that makes sense. > >> > >> Sent from my BlackBerry Z10 smartphone. > >> From: Anis KADRI > >> Sent: Monday, March 18, 2013 1:00 PM > >> To: dev@cordova.apache.org > >> Reply To: dev@cordova.apache.org > >> Subject: Re: archiving older platforms > >> > >> > >> s/QR/Qt > >> > >> > >> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer >> >wrote: > >> > >> > +1 Bada/webOS/QR > >> > > >> > echoing Michael's point, I'd like to see usage stats on the older BB > >> > platforms. BB10 should absolutely be the focus, but If they are > currently > >> > being used, mothballing may be premature. Revisiting the issues > >> regularly, > >> > and making one based on usage stats makes the most sense to me. > >> > > >> > > >> > On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj wrote: > >> > > >> > > +1 all of them, Java and Air implementations of BlackBerry as well. > >> > > > >> > > For the older implementations of BlackBerry, nothing is stopping > anyone > >> > > from using that code. The fact is that Java and Air-related fixes > have > >> > not > >> > > been going in regularly. The implementations are stable enough that > >> > > drawing a line in the sand and saying no more active support for the > >> > older > >> > > BB SDKs is acceptable in my opinion. > >> > > > >> > > On 3/17/13 11:44 AM, "Michael Brooks" > >> wrote: > >> > > > >> > > >> > >> > > >> As far as bb 6 and 7, I am sure the majority of devices out there > >> are > >> > > >>BB 6 > >> > > >> and 7. BB10 just came out so there can't be that many yet. > >> Developers > >> > > >>don't > >> > > >> seem to be interested in those platform though and I think the > focus > >> > > >>should > >> > > >> be on BB10. > >> > > > > >> > > > > >> > > >It would probably be more accurate to say "BlackBerry Java" which > >> > includes > >> > > >BB 4.6/5/6/7 - yep, we "support" all the way back 4.6 although no > one > >> > > >tests > >> > > >that far back anymore. > >> > > > > >> > > >I've heard BlackBerry voice the opinion that they would like to see > >> > Apache > >> > > >Cordova focus solely on BlackBerry 10. However, PhoneGap/Build has > >> seen > >> > a > >> > > >large demand for BlackBerry 5 and 6. > >> > > > > >> > > >+1 Bada > >> > > > > >> > > >+1 webOS - we may want to bring this out of the Attic in the future > >> > > > > >> > > >+1 QR - we may want to bring it this out of the Attic when gearing > up > >> > for > >> > > >Ubuntu Phone > >> > > > > >> > > >+0 BB - I want to talk with the our Pho
Re: archiving older platforms
+1 On 3/21/13 2:12 PM, "Shazron" wrote: >+1 > > >On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny wrote: > >> +1 >> >> >> On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: >> >> > Ok, I think we have agreement that we'll put these guys on hold until >> > they find a steward. This means: >> > >> > - we won't be taggin them further >> > - we won't be including them in a release >> > >> > This does not mean: >> > >> > - deletion or archiving or attic for the src >> > >> > (Think of it as a pause button!) >> > >> > Agree/disagree? >> > >> > On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve >> > wrote: >> > > If there are no fixes going into these platforms, then there is no >> > benefit >> > > in their users updating them to newer versions of Cordova. >> > > >> > > There's going to be more refactoring required when moving plugins to >> > their >> > > own repos. We'll really need owners for all platforms that will make >> the >> > > transition, or else we won't have any way to test that the >>refactoring >> > > hasn't broken a platform. On specific example is that blackberry's >>JS >> > repo >> > > is really 4-in-1 currently, and our plugin spec doesn't have support >> for >> > > this. They will need to be split out into 4 separate platforms, at >> least >> > as >> > > far as the JS is concerned. >> > > >> > > So... I guess my +1 is just for any platform that doesn't have a >> someone >> > > willing to focus on it. E.g. I'm fine with keeping WebOS around if >> Markus >> > > wants to do the work to support it through this transition. >> > > >> > > >> > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis >> >> > wrote: >> > > >> > >> >> > >> We will try to provide relevant stats on platform adoption as we >>are >> > able. >> > >> I am anxiously awaiting that information myself. ;) >> > >> >> > >> While lacking this information, I still feel that BBOS will be >>with us >> > for >> > >> a deal of time, particularly in the enterprise where we are seeing >>a >> > >> significant trend towards Cordova/PhoneGap/WebWorks as the primary >> > platform >> > >> of choice for apps. This is, frustratingly, a difficult market to >>get >> > >> adequate metrics out of, as they will typically not use PhoneGap >>Build >> > IMO, >> > >> and they don't deploy to commercial application stores. A bit of a >> black >> > >> box, but our enterprise support teams continually support the >>notion >> > that >> > >> enterprise looks at HTML5 apps first. >> > >> >> > >> In this regard, we would like to see support for BBOS be >>maintained in >> > the >> > >> short term. Our team is focused on bringing up BlackBerry 10 built >>on >> > >> Cordova, and once that has gotten to a stable point we will then be >> > able to >> > >> look at resources and determine if BBOS is still a valuable >>platform >> to >> > >> support and if we can port BBOS to the new structures. >> > >> >> > >> Hope that makes sense. >> > >> >> > >> Sent from my BlackBerry Z10 smartphone. >> > >> From: Anis KADRI >> > >> Sent: Monday, March 18, 2013 1:00 PM >> > >> To: dev@cordova.apache.org >> > >> Reply To: dev@cordova.apache.org >> > >> Subject: Re: archiving older platforms >> > >> >> > >> >> > >> s/QR/Qt >> > >> >> > >> >> > >> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer >>> > >> >wrote: >> > >> >> > >> > +1 Bada/webOS/QR >> > >> > >> > >> > echoing Michael's point, I'd like to see usage stats on the >>older BB >> > >> > platforms. BB10 should absolutely be the focus, but If they are >> > currently >> > >> > being used, mothballing may be premature. Revisiting the issues >> > >> regularly, >> > >> > and making one based on usage stats makes the most sense to me. >> > >> > >> > >> > >> > >> > On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj >>wrote: >> > >> > >> > >> > > +1 all of them, Java and Air implementations of BlackBerry as >> well. >> > >> > > >> > >> > > For the older implementations of BlackBerry, nothing is >>stopping >> > anyone >> > >> > > from using that code. The fact is that Java and Air-related >>fixes >> > have >> > >> > not >> > >> > > been going in regularly. The implementations are stable enough >> that >> > >> > > drawing a line in the sand and saying no more active support >>for >> the >> > >> > older >> > >> > > BB SDKs is acceptable in my opinion. >> > >> > > >> > >> > > On 3/17/13 11:44 AM, "Michael Brooks" >> >> > >> wrote: >> > >> > > >> > >> > > >> >> > >> > > >> As far as bb 6 and 7, I am sure the majority of devices out >> there >> > >> are >> > >> > > >>BB 6 >> > >> > > >> and 7. BB10 just came out so there can't be that many yet. >> > >> Developers >> > >> > > >>don't >> > >> > > >> seem to be interested in those platform though and I think >>the >> > focus >> > >> > > >>should >> > >> > > >> be on BB10. >> > >> > > > >> > >> > > > >> > >> > > >It would probably be more accurate to say "BlackBerry Java" >>which >> > >> > includes >> > >> > > >BB 4.6/5/6/7 - yep, we "support" all the way back 4.6 >>although no >> > one >> > >> > > >tests >> > >> >
Re: archiving older platforms
+1 On Thu, Mar 21, 2013 at 5:32 PM, Michael Brooks wrote: > +1 > > On Thu, Mar 21, 2013 at 2:12 PM, Shazron wrote: > > > +1 > > > > > > On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny > wrote: > > > > > +1 > > > > > > > > > On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: > > > > > > > Ok, I think we have agreement that we'll put these guys on hold until > > > > they find a steward. This means: > > > > > > > > - we won't be taggin them further > > > > - we won't be including them in a release > > > > > > > > This does not mean: > > > > > > > > - deletion or archiving or attic for the src > > > > > > > > (Think of it as a pause button!) > > > > > > > > Agree/disagree? > > > > > > > > On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve > > > > > wrote: > > > > > If there are no fixes going into these platforms, then there is no > > > > benefit > > > > > in their users updating them to newer versions of Cordova. > > > > > > > > > > There's going to be more refactoring required when moving plugins > to > > > > their > > > > > own repos. We'll really need owners for all platforms that will > make > > > the > > > > > transition, or else we won't have any way to test that the > > refactoring > > > > > hasn't broken a platform. On specific example is that blackberry's > JS > > > > repo > > > > > is really 4-in-1 currently, and our plugin spec doesn't have > support > > > for > > > > > this. They will need to be split out into 4 separate platforms, at > > > least > > > > as > > > > > far as the JS is concerned. > > > > > > > > > > So... I guess my +1 is just for any platform that doesn't have a > > > someone > > > > > willing to focus on it. E.g. I'm fine with keeping WebOS around if > > > Markus > > > > > wants to do the work to support it through this transition. > > > > > > > > > > > > > > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis < > kwal...@blackberry.com > > > > > > > wrote: > > > > > > > > > >> > > > > >> We will try to provide relevant stats on platform adoption as we > are > > > > able. > > > > >> I am anxiously awaiting that information myself. ;) > > > > >> > > > > >> While lacking this information, I still feel that BBOS will be > with > > us > > > > for > > > > >> a deal of time, particularly in the enterprise where we are > seeing a > > > > >> significant trend towards Cordova/PhoneGap/WebWorks as the primary > > > > platform > > > > >> of choice for apps. This is, frustratingly, a difficult market to > > get > > > > >> adequate metrics out of, as they will typically not use PhoneGap > > Build > > > > IMO, > > > > >> and they don't deploy to commercial application stores. A bit of a > > > black > > > > >> box, but our enterprise support teams continually support the > notion > > > > that > > > > >> enterprise looks at HTML5 apps first. > > > > >> > > > > >> In this regard, we would like to see support for BBOS be > maintained > > in > > > > the > > > > >> short term. Our team is focused on bringing up BlackBerry 10 built > > on > > > > >> Cordova, and once that has gotten to a stable point we will then > be > > > > able to > > > > >> look at resources and determine if BBOS is still a valuable > platform > > > to > > > > >> support and if we can port BBOS to the new structures. > > > > >> > > > > >> Hope that makes sense. > > > > >> > > > > >> Sent from my BlackBerry Z10 smartphone. > > > > >> From: Anis KADRI > > > > >> Sent: Monday, March 18, 2013 1:00 PM > > > > >> To: dev@cordova.apache.org > > > > >> Reply To: dev@cordova.apache.org > > > > >> Subject: Re: archiving older platforms > > > > >> > > > > >> > > > > >> s/QR/Qt > > > > >> > > > > >> > > > > >> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer < > > lorin.beer@gmail.com > > > > >> >wrote: > > > > >> > > > > >> > +1 Bada/webOS/QR > > > > >> > > > > > >> > echoing Michael's point, I'd like to see usage stats on the > older > > BB > > > > >> > platforms. BB10 should absolutely be the focus, but If they are > > > > currently > > > > >> > being used, mothballing may be premature. Revisiting the issues > > > > >> regularly, > > > > >> > and making one based on usage stats makes the most sense to me. > > > > >> > > > > > >> > > > > > >> > On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj > > wrote: > > > > >> > > > > > >> > > +1 all of them, Java and Air implementations of BlackBerry as > > > well. > > > > >> > > > > > > >> > > For the older implementations of BlackBerry, nothing is > stopping > > > > anyone > > > > >> > > from using that code. The fact is that Java and Air-related > > fixes > > > > have > > > > >> > not > > > > >> > > been going in regularly. The implementations are stable enough > > > that > > > > >> > > drawing a line in the sand and saying no more active support > for > > > the > > > > >> > older > > > > >> > > BB SDKs is acceptable in my opinion. > > > > >> > > > > > > >> > > On 3/17/13 11:44 AM, "Michael Brooks" < > mich...@michaelbrooks.ca > > > > > > > >> wrote: > > > > >> > > > > > > >> > > >> > > > > >> > > >> As fa
Re: Platform-level command line scripts
On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks wrote: > +1 Fil's outlined design. > > I'm still not convinced of what Anis and Andrew are in favour of. Having > each script do more will make it more difficult for common results across > all platforms. > > I really like Anis's suggestion of just four scripts. What's the motivation > > for having many scripts? Having fewer will dramatically reduce copy & > paste > > bugs. It will also aid discoverability (since you'll get --help instead > of > > just "ls" and infer from the name what they do). > > > The motivation for having many scripts is that there is a single entry > point for a single action. Each action is discrete. Either a platform > supports `deploy-emulator` or doesn't. If we have a single `run` > entry-point, it becomes confusing whether a platform supports all > requirements of the `run` action. > > I feel the code repetition is also a weak argument. We are defining > entry-point scripts. You can refactor out the common routines (e.g. build) > into a helper script that can be invoked by multiple scripts. As far as I > know, this is possible in bash, batch, and Windows Script Hosting. > I guess this topic will need a vote to follow the Apache Way. We've been talking about/implementing/changing these scripts for a long time and we can't seem to come to a complete agreement. > > ripple should be a separate option and not a separate command in my > > opinion. To simplify things and if everyone agrees we can ignore the > `run` > > command flow above and launch ripple by default and ask users to specify > > options if they want to deploy and run to a particular device/emulator. > > > I feel Ripple has no place in the platform-specific scripts. I love Ripple, > but Ripple belongs is a higher-level tool such as Cordova CLI. The > platform-specific scripts are meant to deal with platform-specific > functions. > I don't have a strong opinion on this. So I could agree with you that this Ripple could be a higher-level tool. > > Michael > > On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes wrote: > > > I liked the idea you mentioned earlier with having one wrapper script, > > that way there is one entry point for the given commands for the needed > > functionality. Then it doesn't matter what underlying scripts actually do > > the work. > > > > Then our only focus would be on the commands and not so much the name of > > the scripts. > > > > > > On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve > > wrote: > > > > > I really like Anis's suggestion of just four scripts. What's the > > motivation > > > for having many scripts? Having fewer will dramatically reduce copy & > > paste > > > bugs. It will also aid discoverability (since you'll get --help instead > > of > > > just "ls" and infer from the name what they do). > > > > > > > > > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: > > > > > > > Ya ya ya we're all on agreement on this specific issue. The > underlying > > > > platform scripts can be used regardless of whether you're using > > > > cordova-cli or not. > > > > > > > > On 3/20/13 3:51 PM, "Anis KADRI" wrote: > > > > > > > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes > > > wrote: > > > > > > > > > >> I know that sounds > > > > >> like a lot > > > > >> of scripts but we're building them for the cordova-cli to use, > so i > > > > >>like > > > > >> the idea of breaking > > > > >> them out so each script does a *very specific* task with as > > > > >>little-to-no > > > > >> > > > > > > > > > >No we're not. cordova-cli is a cool tool that people can use but it > > > should > > > > >not be the only way of building Cordova apps in my opinion. > > > > > > > > > > > > > >
Re: Pull requests done
Yup :) On Thu, Mar 21, 2013 at 2:20 PM, Tommy-Carlos Williams wrote: > Shazron, > > So do your FileTransfer tests resolve CB-2687 [1] ? > > [1] https://issues.apache.org/jira/browse/CB-2687 > > > On 22/03/2013, at 3:22 AM, Shazron wrote: > > > Thanks Andrew! > > I've got new mobile-spec FileTransfer tests in for the new basic auth > > upload/download plus the corresponding new deployed > > cordova-filetransfer.jitsu.com script. There might be failures on some > > platforms for these 2 new tests (WP7 comes to mind since it doesn't > support > > window.btoa in JavaScript) > > > > I'd like to get some doc changes in for today (iOS / OS X) but I suppose > we > > can get the release train running... > > > > > > On Thu, Mar 21, 2013 at 2:00 AM, Xavier wrote: > > > >>> Noticed a cordova-js pull request for Windows > >> > >> If you are referring to "Windows build (CB-1667 and CB-2588)" [1], I'd > >> like to clarify that it is about Windows as a development platform > >> [2][3], not as a cordova platform > >> > >> [1] https://github.com/apache/cordova-js/pull/14 > >> [2] https://issues.apache.org/jira/browse/CB-1667 > >> [3] https://issues.apache.org/jira/browse/CB-2588 > >> > >> -Xavier > >> > >
Re: archiving older platforms
+1 On Thu, Mar 21, 2013 at 2:12 PM, Shazron wrote: > +1 > > > On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny wrote: > > > +1 > > > > > > On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: > > > > > Ok, I think we have agreement that we'll put these guys on hold until > > > they find a steward. This means: > > > > > > - we won't be taggin them further > > > - we won't be including them in a release > > > > > > This does not mean: > > > > > > - deletion or archiving or attic for the src > > > > > > (Think of it as a pause button!) > > > > > > Agree/disagree? > > > > > > On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve > > > wrote: > > > > If there are no fixes going into these platforms, then there is no > > > benefit > > > > in their users updating them to newer versions of Cordova. > > > > > > > > There's going to be more refactoring required when moving plugins to > > > their > > > > own repos. We'll really need owners for all platforms that will make > > the > > > > transition, or else we won't have any way to test that the > refactoring > > > > hasn't broken a platform. On specific example is that blackberry's JS > > > repo > > > > is really 4-in-1 currently, and our plugin spec doesn't have support > > for > > > > this. They will need to be split out into 4 separate platforms, at > > least > > > as > > > > far as the JS is concerned. > > > > > > > > So... I guess my +1 is just for any platform that doesn't have a > > someone > > > > willing to focus on it. E.g. I'm fine with keeping WebOS around if > > Markus > > > > wants to do the work to support it through this transition. > > > > > > > > > > > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis > > > > wrote: > > > > > > > >> > > > >> We will try to provide relevant stats on platform adoption as we are > > > able. > > > >> I am anxiously awaiting that information myself. ;) > > > >> > > > >> While lacking this information, I still feel that BBOS will be with > us > > > for > > > >> a deal of time, particularly in the enterprise where we are seeing a > > > >> significant trend towards Cordova/PhoneGap/WebWorks as the primary > > > platform > > > >> of choice for apps. This is, frustratingly, a difficult market to > get > > > >> adequate metrics out of, as they will typically not use PhoneGap > Build > > > IMO, > > > >> and they don't deploy to commercial application stores. A bit of a > > black > > > >> box, but our enterprise support teams continually support the notion > > > that > > > >> enterprise looks at HTML5 apps first. > > > >> > > > >> In this regard, we would like to see support for BBOS be maintained > in > > > the > > > >> short term. Our team is focused on bringing up BlackBerry 10 built > on > > > >> Cordova, and once that has gotten to a stable point we will then be > > > able to > > > >> look at resources and determine if BBOS is still a valuable platform > > to > > > >> support and if we can port BBOS to the new structures. > > > >> > > > >> Hope that makes sense. > > > >> > > > >> Sent from my BlackBerry Z10 smartphone. > > > >> From: Anis KADRI > > > >> Sent: Monday, March 18, 2013 1:00 PM > > > >> To: dev@cordova.apache.org > > > >> Reply To: dev@cordova.apache.org > > > >> Subject: Re: archiving older platforms > > > >> > > > >> > > > >> s/QR/Qt > > > >> > > > >> > > > >> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer < > lorin.beer@gmail.com > > > >> >wrote: > > > >> > > > >> > +1 Bada/webOS/QR > > > >> > > > > >> > echoing Michael's point, I'd like to see usage stats on the older > BB > > > >> > platforms. BB10 should absolutely be the focus, but If they are > > > currently > > > >> > being used, mothballing may be premature. Revisiting the issues > > > >> regularly, > > > >> > and making one based on usage stats makes the most sense to me. > > > >> > > > > >> > > > > >> > On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj > wrote: > > > >> > > > > >> > > +1 all of them, Java and Air implementations of BlackBerry as > > well. > > > >> > > > > > >> > > For the older implementations of BlackBerry, nothing is stopping > > > anyone > > > >> > > from using that code. The fact is that Java and Air-related > fixes > > > have > > > >> > not > > > >> > > been going in regularly. The implementations are stable enough > > that > > > >> > > drawing a line in the sand and saying no more active support for > > the > > > >> > older > > > >> > > BB SDKs is acceptable in my opinion. > > > >> > > > > > >> > > On 3/17/13 11:44 AM, "Michael Brooks" > > > > >> wrote: > > > >> > > > > > >> > > >> > > > >> > > >> As far as bb 6 and 7, I am sure the majority of devices out > > there > > > >> are > > > >> > > >>BB 6 > > > >> > > >> and 7. BB10 just came out so there can't be that many yet. > > > >> Developers > > > >> > > >>don't > > > >> > > >> seem to be interested in those platform though and I think > the > > > focus > > > >> > > >>should > > > >> > > >> be on BB10. > > > >> > > > > > > >> > > > > > > >> > > >It would probably be more accurate to sa
Re: Platform-level command line scripts
+1 Fil's outlined design. I'm still not convinced of what Anis and Andrew are in favour of. Having each script do more will make it more difficult for common results across all platforms. I really like Anis's suggestion of just four scripts. What's the motivation > for having many scripts? Having fewer will dramatically reduce copy & paste > bugs. It will also aid discoverability (since you'll get --help instead of > just "ls" and infer from the name what they do). The motivation for having many scripts is that there is a single entry point for a single action. Each action is discrete. Either a platform supports `deploy-emulator` or doesn't. If we have a single `run` entry-point, it becomes confusing whether a platform supports all requirements of the `run` action. I feel the code repetition is also a weak argument. We are defining entry-point scripts. You can refactor out the common routines (e.g. build) into a helper script that can be invoked by multiple scripts. As far as I know, this is possible in bash, batch, and Windows Script Hosting. ripple should be a separate option and not a separate command in my > opinion. To simplify things and if everyone agrees we can ignore the `run` > command flow above and launch ripple by default and ask users to specify > options if they want to deploy and run to a particular device/emulator. I feel Ripple has no place in the platform-specific scripts. I love Ripple, but Ripple belongs is a higher-level tool such as Cordova CLI. The platform-specific scripts are meant to deal with platform-specific functions. Michael On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes wrote: > I liked the idea you mentioned earlier with having one wrapper script, > that way there is one entry point for the given commands for the needed > functionality. Then it doesn't matter what underlying scripts actually do > the work. > > Then our only focus would be on the commands and not so much the name of > the scripts. > > > On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve > wrote: > > > I really like Anis's suggestion of just four scripts. What's the > motivation > > for having many scripts? Having fewer will dramatically reduce copy & > paste > > bugs. It will also aid discoverability (since you'll get --help instead > of > > just "ls" and infer from the name what they do). > > > > > > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: > > > > > Ya ya ya we're all on agreement on this specific issue. The underlying > > > platform scripts can be used regardless of whether you're using > > > cordova-cli or not. > > > > > > On 3/20/13 3:51 PM, "Anis KADRI" wrote: > > > > > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes > > wrote: > > > > > > > >> I know that sounds > > > >> like a lot > > > >> of scripts but we're building them for the cordova-cli to use, so i > > > >>like > > > >> the idea of breaking > > > >> them out so each script does a *very specific* task with as > > > >>little-to-no > > > >> > > > > > > > >No we're not. cordova-cli is a cool tool that people can use but it > > should > > > >not be the only way of building Cordova apps in my opinion. > > > > > > > > >
Re: Pull requests done
Shazron, So do your FileTransfer tests resolve CB-2687 [1] ? [1] https://issues.apache.org/jira/browse/CB-2687 On 22/03/2013, at 3:22 AM, Shazron wrote: > Thanks Andrew! > I've got new mobile-spec FileTransfer tests in for the new basic auth > upload/download plus the corresponding new deployed > cordova-filetransfer.jitsu.com script. There might be failures on some > platforms for these 2 new tests (WP7 comes to mind since it doesn't support > window.btoa in JavaScript) > > I'd like to get some doc changes in for today (iOS / OS X) but I suppose we > can get the release train running... > > > On Thu, Mar 21, 2013 at 2:00 AM, Xavier wrote: > >>> Noticed a cordova-js pull request for Windows >> >> If you are referring to "Windows build (CB-1667 and CB-2588)" [1], I'd >> like to clarify that it is about Windows as a development platform >> [2][3], not as a cordova platform >> >> [1] https://github.com/apache/cordova-js/pull/14 >> [2] https://issues.apache.org/jira/browse/CB-1667 >> [3] https://issues.apache.org/jira/browse/CB-2588 >> >> -Xavier >>
Re: archiving older platforms
+1 On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny wrote: > +1 > > > On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: > > > Ok, I think we have agreement that we'll put these guys on hold until > > they find a steward. This means: > > > > - we won't be taggin them further > > - we won't be including them in a release > > > > This does not mean: > > > > - deletion or archiving or attic for the src > > > > (Think of it as a pause button!) > > > > Agree/disagree? > > > > On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve > > wrote: > > > If there are no fixes going into these platforms, then there is no > > benefit > > > in their users updating them to newer versions of Cordova. > > > > > > There's going to be more refactoring required when moving plugins to > > their > > > own repos. We'll really need owners for all platforms that will make > the > > > transition, or else we won't have any way to test that the refactoring > > > hasn't broken a platform. On specific example is that blackberry's JS > > repo > > > is really 4-in-1 currently, and our plugin spec doesn't have support > for > > > this. They will need to be split out into 4 separate platforms, at > least > > as > > > far as the JS is concerned. > > > > > > So... I guess my +1 is just for any platform that doesn't have a > someone > > > willing to focus on it. E.g. I'm fine with keeping WebOS around if > Markus > > > wants to do the work to support it through this transition. > > > > > > > > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis > > wrote: > > > > > >> > > >> We will try to provide relevant stats on platform adoption as we are > > able. > > >> I am anxiously awaiting that information myself. ;) > > >> > > >> While lacking this information, I still feel that BBOS will be with us > > for > > >> a deal of time, particularly in the enterprise where we are seeing a > > >> significant trend towards Cordova/PhoneGap/WebWorks as the primary > > platform > > >> of choice for apps. This is, frustratingly, a difficult market to get > > >> adequate metrics out of, as they will typically not use PhoneGap Build > > IMO, > > >> and they don't deploy to commercial application stores. A bit of a > black > > >> box, but our enterprise support teams continually support the notion > > that > > >> enterprise looks at HTML5 apps first. > > >> > > >> In this regard, we would like to see support for BBOS be maintained in > > the > > >> short term. Our team is focused on bringing up BlackBerry 10 built on > > >> Cordova, and once that has gotten to a stable point we will then be > > able to > > >> look at resources and determine if BBOS is still a valuable platform > to > > >> support and if we can port BBOS to the new structures. > > >> > > >> Hope that makes sense. > > >> > > >> Sent from my BlackBerry Z10 smartphone. > > >> From: Anis KADRI > > >> Sent: Monday, March 18, 2013 1:00 PM > > >> To: dev@cordova.apache.org > > >> Reply To: dev@cordova.apache.org > > >> Subject: Re: archiving older platforms > > >> > > >> > > >> s/QR/Qt > > >> > > >> > > >> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer > >> >wrote: > > >> > > >> > +1 Bada/webOS/QR > > >> > > > >> > echoing Michael's point, I'd like to see usage stats on the older BB > > >> > platforms. BB10 should absolutely be the focus, but If they are > > currently > > >> > being used, mothballing may be premature. Revisiting the issues > > >> regularly, > > >> > and making one based on usage stats makes the most sense to me. > > >> > > > >> > > > >> > On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj wrote: > > >> > > > >> > > +1 all of them, Java and Air implementations of BlackBerry as > well. > > >> > > > > >> > > For the older implementations of BlackBerry, nothing is stopping > > anyone > > >> > > from using that code. The fact is that Java and Air-related fixes > > have > > >> > not > > >> > > been going in regularly. The implementations are stable enough > that > > >> > > drawing a line in the sand and saying no more active support for > the > > >> > older > > >> > > BB SDKs is acceptable in my opinion. > > >> > > > > >> > > On 3/17/13 11:44 AM, "Michael Brooks" > > >> wrote: > > >> > > > > >> > > >> > > >> > > >> As far as bb 6 and 7, I am sure the majority of devices out > there > > >> are > > >> > > >>BB 6 > > >> > > >> and 7. BB10 just came out so there can't be that many yet. > > >> Developers > > >> > > >>don't > > >> > > >> seem to be interested in those platform though and I think the > > focus > > >> > > >>should > > >> > > >> be on BB10. > > >> > > > > > >> > > > > > >> > > >It would probably be more accurate to say "BlackBerry Java" which > > >> > includes > > >> > > >BB 4.6/5/6/7 - yep, we "support" all the way back 4.6 although no > > one > > >> > > >tests > > >> > > >that far back anymore. > > >> > > > > > >> > > >I've heard BlackBerry voice the opinion that they would like to > see > > >> > Apache > > >> > > >Cordova focus solely on BlackBerry 10. However, PhoneGap/Build > has > > >> seen > >
Re: archiving older platforms
+1 On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: > Ok, I think we have agreement that we'll put these guys on hold until > they find a steward. This means: > > - we won't be taggin them further > - we won't be including them in a release > > This does not mean: > > - deletion or archiving or attic for the src > > (Think of it as a pause button!) > > Agree/disagree? > > On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve > wrote: > > If there are no fixes going into these platforms, then there is no > benefit > > in their users updating them to newer versions of Cordova. > > > > There's going to be more refactoring required when moving plugins to > their > > own repos. We'll really need owners for all platforms that will make the > > transition, or else we won't have any way to test that the refactoring > > hasn't broken a platform. On specific example is that blackberry's JS > repo > > is really 4-in-1 currently, and our plugin spec doesn't have support for > > this. They will need to be split out into 4 separate platforms, at least > as > > far as the JS is concerned. > > > > So... I guess my +1 is just for any platform that doesn't have a someone > > willing to focus on it. E.g. I'm fine with keeping WebOS around if Markus > > wants to do the work to support it through this transition. > > > > > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis > wrote: > > > >> > >> We will try to provide relevant stats on platform adoption as we are > able. > >> I am anxiously awaiting that information myself. ;) > >> > >> While lacking this information, I still feel that BBOS will be with us > for > >> a deal of time, particularly in the enterprise where we are seeing a > >> significant trend towards Cordova/PhoneGap/WebWorks as the primary > platform > >> of choice for apps. This is, frustratingly, a difficult market to get > >> adequate metrics out of, as they will typically not use PhoneGap Build > IMO, > >> and they don't deploy to commercial application stores. A bit of a black > >> box, but our enterprise support teams continually support the notion > that > >> enterprise looks at HTML5 apps first. > >> > >> In this regard, we would like to see support for BBOS be maintained in > the > >> short term. Our team is focused on bringing up BlackBerry 10 built on > >> Cordova, and once that has gotten to a stable point we will then be > able to > >> look at resources and determine if BBOS is still a valuable platform to > >> support and if we can port BBOS to the new structures. > >> > >> Hope that makes sense. > >> > >> Sent from my BlackBerry Z10 smartphone. > >> From: Anis KADRI > >> Sent: Monday, March 18, 2013 1:00 PM > >> To: dev@cordova.apache.org > >> Reply To: dev@cordova.apache.org > >> Subject: Re: archiving older platforms > >> > >> > >> s/QR/Qt > >> > >> > >> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer >> >wrote: > >> > >> > +1 Bada/webOS/QR > >> > > >> > echoing Michael's point, I'd like to see usage stats on the older BB > >> > platforms. BB10 should absolutely be the focus, but If they are > currently > >> > being used, mothballing may be premature. Revisiting the issues > >> regularly, > >> > and making one based on usage stats makes the most sense to me. > >> > > >> > > >> > On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj wrote: > >> > > >> > > +1 all of them, Java and Air implementations of BlackBerry as well. > >> > > > >> > > For the older implementations of BlackBerry, nothing is stopping > anyone > >> > > from using that code. The fact is that Java and Air-related fixes > have > >> > not > >> > > been going in regularly. The implementations are stable enough that > >> > > drawing a line in the sand and saying no more active support for the > >> > older > >> > > BB SDKs is acceptable in my opinion. > >> > > > >> > > On 3/17/13 11:44 AM, "Michael Brooks" > >> wrote: > >> > > > >> > > >> > >> > > >> As far as bb 6 and 7, I am sure the majority of devices out there > >> are > >> > > >>BB 6 > >> > > >> and 7. BB10 just came out so there can't be that many yet. > >> Developers > >> > > >>don't > >> > > >> seem to be interested in those platform though and I think the > focus > >> > > >>should > >> > > >> be on BB10. > >> > > > > >> > > > > >> > > >It would probably be more accurate to say "BlackBerry Java" which > >> > includes > >> > > >BB 4.6/5/6/7 - yep, we "support" all the way back 4.6 although no > one > >> > > >tests > >> > > >that far back anymore. > >> > > > > >> > > >I've heard BlackBerry voice the opinion that they would like to see > >> > Apache > >> > > >Cordova focus solely on BlackBerry 10. However, PhoneGap/Build has > >> seen > >> > a > >> > > >large demand for BlackBerry 5 and 6. > >> > > > > >> > > >+1 Bada > >> > > > > >> > > >+1 webOS - we may want to bring this out of the Attic in the future > >> > > > > >> > > >+1 QR - we may want to bring it this out of the Attic when gearing > up > >> > for > >> > > >Ubuntu Phone > >> > > > > >> > > >+0 BB - I want to talk with the our Pho
Re: archiving older platforms
Ok, I think we have agreement that we'll put these guys on hold until they find a steward. This means: - we won't be taggin them further - we won't be including them in a release This does not mean: - deletion or archiving or attic for the src (Think of it as a pause button!) Agree/disagree? On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve wrote: > If there are no fixes going into these platforms, then there is no benefit > in their users updating them to newer versions of Cordova. > > There's going to be more refactoring required when moving plugins to their > own repos. We'll really need owners for all platforms that will make the > transition, or else we won't have any way to test that the refactoring > hasn't broken a platform. On specific example is that blackberry's JS repo > is really 4-in-1 currently, and our plugin spec doesn't have support for > this. They will need to be split out into 4 separate platforms, at least as > far as the JS is concerned. > > So... I guess my +1 is just for any platform that doesn't have a someone > willing to focus on it. E.g. I'm fine with keeping WebOS around if Markus > wants to do the work to support it through this transition. > > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis wrote: > >> >> We will try to provide relevant stats on platform adoption as we are able. >> I am anxiously awaiting that information myself. ;) >> >> While lacking this information, I still feel that BBOS will be with us for >> a deal of time, particularly in the enterprise where we are seeing a >> significant trend towards Cordova/PhoneGap/WebWorks as the primary platform >> of choice for apps. This is, frustratingly, a difficult market to get >> adequate metrics out of, as they will typically not use PhoneGap Build IMO, >> and they don't deploy to commercial application stores. A bit of a black >> box, but our enterprise support teams continually support the notion that >> enterprise looks at HTML5 apps first. >> >> In this regard, we would like to see support for BBOS be maintained in the >> short term. Our team is focused on bringing up BlackBerry 10 built on >> Cordova, and once that has gotten to a stable point we will then be able to >> look at resources and determine if BBOS is still a valuable platform to >> support and if we can port BBOS to the new structures. >> >> Hope that makes sense. >> >> Sent from my BlackBerry Z10 smartphone. >> From: Anis KADRI >> Sent: Monday, March 18, 2013 1:00 PM >> To: dev@cordova.apache.org >> Reply To: dev@cordova.apache.org >> Subject: Re: archiving older platforms >> >> >> s/QR/Qt >> >> >> On Mon, Mar 18, 2013 at 8:58 AM, Lorin Beer > >wrote: >> >> > +1 Bada/webOS/QR >> > >> > echoing Michael's point, I'd like to see usage stats on the older BB >> > platforms. BB10 should absolutely be the focus, but If they are currently >> > being used, mothballing may be premature. Revisiting the issues >> regularly, >> > and making one based on usage stats makes the most sense to me. >> > >> > >> > On Sun, Mar 17, 2013 at 11:56 AM, Filip Maj wrote: >> > >> > > +1 all of them, Java and Air implementations of BlackBerry as well. >> > > >> > > For the older implementations of BlackBerry, nothing is stopping anyone >> > > from using that code. The fact is that Java and Air-related fixes have >> > not >> > > been going in regularly. The implementations are stable enough that >> > > drawing a line in the sand and saying no more active support for the >> > older >> > > BB SDKs is acceptable in my opinion. >> > > >> > > On 3/17/13 11:44 AM, "Michael Brooks" >> wrote: >> > > >> > > >> >> > > >> As far as bb 6 and 7, I am sure the majority of devices out there >> are >> > > >>BB 6 >> > > >> and 7. BB10 just came out so there can't be that many yet. >> Developers >> > > >>don't >> > > >> seem to be interested in those platform though and I think the focus >> > > >>should >> > > >> be on BB10. >> > > > >> > > > >> > > >It would probably be more accurate to say "BlackBerry Java" which >> > includes >> > > >BB 4.6/5/6/7 - yep, we "support" all the way back 4.6 although no one >> > > >tests >> > > >that far back anymore. >> > > > >> > > >I've heard BlackBerry voice the opinion that they would like to see >> > Apache >> > > >Cordova focus solely on BlackBerry 10. However, PhoneGap/Build has >> seen >> > a >> > > >large demand for BlackBerry 5 and 6. >> > > > >> > > >+1 Bada >> > > > >> > > >+1 webOS - we may want to bring this out of the Attic in the future >> > > > >> > > >+1 QR - we may want to bring it this out of the Attic when gearing up >> > for >> > > >Ubuntu Phone >> > > > >> > > >+0 BB - I want to talk with the our PhoneGap/Build team to better >> > > >understand their stance. I'd also like Ken or Jeff from BlackBerry to >> > > >chime >> > > >in with their opinion. >> > > > >> > > >On Sun, Mar 17, 2013 at 10:11 AM, Anis KADRI >> > > wrote: >> > > > >> > > >> +1 to kill those platforms and archive them in the attic :-D >> > > >> >> > > >> If WebOS, Qt beco
Re: Platform-level command line scripts ;)
Ya tend to agree w/ the workflows you describe Jesse. Not at the exlusion of discreet scripts however. We probably should have small focused scripts and then compose the workflow scripts from them. (Making it easier to test and compose new scripts and tooling.) On Thu, Mar 21, 2013 at 12:07 AM, Jesse wrote: > renaming stuff is easy. > > Does it make sense to log without running? or does log also launch? where? > Sounds to me like logging is an option attached to a run command. > What is the point of cleaning if you're not going to build right after? > trying to free up hard drive space? anal much? or is clean just a build > option? > > The current state of WP7+WP8 > > Every WP7 and WP8 cordova project that you create with the create script, > or with the template has a debug and an emulate command. > debug: builds and runs on the attached device. > emulate : builds and runs on the first emulator, starting it if it was not > already running > > > > > @purplecabbage > risingj.com > > > On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes wrote: > >> I liked the idea you mentioned earlier with having one wrapper script, >> that way there is one entry point for the given commands for the needed >> functionality. Then it doesn't matter what underlying scripts actually do >> the work. >> >> Then our only focus would be on the commands and not so much the name of >> the scripts. >> >> >> On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve >> wrote: >> >> > I really like Anis's suggestion of just four scripts. What's the >> motivation >> > for having many scripts? Having fewer will dramatically reduce copy & >> paste >> > bugs. It will also aid discoverability (since you'll get --help instead >> of >> > just "ls" and infer from the name what they do). >> > >> > >> > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: >> > >> > > Ya ya ya we're all on agreement on this specific issue. The underlying >> > > platform scripts can be used regardless of whether you're using >> > > cordova-cli or not. >> > > >> > > On 3/20/13 3:51 PM, "Anis KADRI" wrote: >> > > >> > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes >> > wrote: >> > > > >> > > >> I know that sounds >> > > >> like a lot >> > > >> of scripts but we're building them for the cordova-cli to use, so i >> > > >>like >> > > >> the idea of breaking >> > > >> them out so each script does a *very specific* task with as >> > > >>little-to-no >> > > >> >> > > > >> > > >No we're not. cordova-cli is a cool tool that people can use but it >> > should >> > > >not be the only way of building Cordova apps in my opinion. >> > > >> > > >> > >>
Re: sysapps runtime cfc passed
While I respect the benefits I really doubt we can get rid of eval and inline scripts ever. Thats the nature of the web. Subsequent efforts that forget this facet of the web and pretend to fix the issue have thus far tended to fail. In any case, we are unable to fix this issue unless we start shipping a browser, which we're not going to do anytime soon if ever at all. On Wed, Mar 20, 2013 at 2:23 PM, Filip Maj wrote: > Ah thanks for clarifying > > On 3/20/13 2:17 PM, "Andrew Lunny" wrote: > >>On 20 March 2013 13:54, Filip Maj wrote: >> >>> Actually dude talks about CSP 1.1 supporting whitelisting of inline >>> scripts ? >>> >> >>The relevant bit in the CSP spec is: >>http://www.w3.org/TR/CSP/#script-src >> >>tldr: servers can send CSPs (policies) that do allow inline scripts, but >>the policy specified by sysapps[1] does not. >> >>[1] default-src *; script-src 'self'; object-src 'none'; style-src 'self' >> >> >>> >>> On 3/20/13 8:39 AM, "Andrew Grieve" wrote: >>> >>> >This recent security talk talks about why inline scripts are on the way >>> >out: >>> >https://www.youtube.com/watch?feature=player_embedded&v=WljJ5guzcLs >>> > >>> >A good amount of the spec deals with application distribution, which is >>> >out >>> >of our hands when talking about App Stores. >>> > >>> >It uses a separate AppCache manifest to define what files are in the >>> >bundle. Does this not imply that the whitelist is still in effect via >>>the >>> >Network: section of the AppCache manifest? >>> > >>> > >>> > >>> > >>> > >>> >On Wed, Mar 20, 2013 at 10:10 AM, Braden Shepherdson >>> >wrote: >>> > >>> >> On the subject of no inline scripts or eval, this is used in the new >>>v2 >>> >> Chrome Apps too. It eliminates a wide spectrum of security risks at a >>> >> stroke, though it does require changing some of the older web dev >>> >>practices >>> >> (onclick="whatever", primarily). If you're already attaching handlers >>> >>using >>> >> jQuery, or using something like AngularJS, this is no change. >>> >> >>> >> Only loading scripts from inside the app package, I'm not sure. It >>> >> eliminates the possibility of using a CDN, but the caching benefits >>>of >>> >>that >>> >> are inferior to shipping the files in the bundle. >>> >> >>> >> Braden >>> >> >>> >> >>> >> On Wed, Mar 20, 2013 at 6:46 AM, Brian LeRoux wrote: >>> >> >>> >> > Ok, picking this up again. At the working group Fil it would be >>>good >>> >> > to give our feedback on the manifest as it has related to the >>>Cordova >>> >> > reality. >>> >> > >>> >> > I really dislike: >>> >> > >>> >> > - scripts can only be loaded from inside the app package >>> >> > - no inline scripts, no eval >>> >> > >>> >> > I really like the idea of killing the whitelist feature.. >>> >> > >>> >> > >>> >> > On Tue, Mar 19, 2013 at 7:06 AM, Michal Mocny >>> >> wrote: >>> >> > > Thanks for the highlights Fil. Makes for easier reading! >>> >> > > >>> >> > > >>> >> > > On Mon, Mar 18, 2013 at 5:21 PM, Filip Maj wrote: >>> >> > > >>> >> > >> Highlights w.r.t. Cordova: >>> >> > >> >>> >> > >> 1. Application manifest JSON (yay!) [1]: >>> >> > >> >>> >> > >> 2. There is an Application interface now in charge of handling: >>> >> > >> - pause/resume/launch/terminate events >>> >> > >> - readonly parameters such as install time, origin, >>>parameters, >>> >> update >>> >> > >> state (downloading, installing), package size >>> >> > >> - methods such as exit, hide, uninstall, update (interesting!) >>> >> > >> - related to update, the spec calls for the update firing >>> >> > >> asynchronously, reporting back progress events to the app. >>>met >>> >> > >> 3. App Management interface, which is deemed as a "privileged" >>> >>API, to >>> >> > get >>> >> > >> events about the (un)installation of other applications. >>> >> > >> >>> >> > >> Interesting "security" conclusions [2]: >>> >> > >> >>> >> > >> - scripts can only be loaded from inside the app package >>> >> > >> - no inline scripts, no eval >>> >> > >> - "Media (audio and video) can still be loaded from anywhere;" >>>=> >>> >>this >>> >> > >> should inform our media APIs once we get to the audit and >>>finally >>> >> > >> determine that the whitelist has no effect on media. This >>>already >>> >> > applies >>> >> > >> to images on the web. >>> >> > >> - "Network connections can still be opened anywhere using >>> >>data-centric >>> >> > >> APIs like XMLHttpRequest or WebSocket." => implication here is >>>that >>> >> the >>> >> > >> whitelist is, really, useless (which has been my opinion always >>>:D >>> >>) >>> >> > >> >>> >> > >> Related, I will be attending the SysApps Face to Face in madrid >>>[3] >>> >> next >>> >> > >> month. If anyone from the Cordova community has specific issues >>> >>that >>> >> > they >>> >> > >> would like to see addressed, let me know! >>> >> > >> >>> >> > >> [1] http://runtime.sysapps.org/#application-manifest >>> >> > >> [2] http://runtime.sysapps.org/#csp-policy >>> >> > >> [3] >>> >> http://www.w3.org
Re: tag 2.6.0rc1 soon?
I think your prioritization is correct. It would be great to ship w/ our docs but no rush. On Thu, Mar 21, 2013 at 11:36 AM, Braden Shepherdson wrote: > Yes, that's on my list of things to do. I'm making progress along that > list, but it's currently outrunning me. > > Do people like the idea of putting this doc into the docs.cordova.io docs? > Or do we prefer to keep contributor-related things in the wiki? If the > latter, it can wait, but if the former then I should probably commit it > very soon. > > Braden > > > On Thu, Mar 21, 2013 at 1:58 PM, Brian LeRoux wrote: > >> Braden also published this detailed guide for contributors on the topic: >> >> >> https://googledrive.com/host/0B8sLcyOAEX-XUHAxNXhISE5rTTg/guide_contributing_index.md.html >> >> (Which I'm guessing will make its way into our docs proper?) >> >> >> On Thu, Mar 21, 2013 at 10:09 AM, Filip Maj wrote: >> > Alright folks, mobile-spec and cordova-js are tagged 2.6.0rc1, and the >> > 2.6.x branches on both those repos are now pushed up. Gogo release mode! >> > >> > On 3/21/13 9:12 AM, "James Jong" wrote: >> > >> >>Nice. Thanks Michal. >> >> >> >>-James Jong >> >> >> >>On Mar 21, 2013, at 11:57 AM, Michal Mocny wrote: >> >> >> >>> Yes, the intent is to have living branches. We may also cherry-pick >> >>> regressions back to more than just the current release. >> >>> >> >>> >> >>> On Thu, Mar 21, 2013 at 11:50 AM, James Jong >> >>>wrote: >> >>> >> Thanks Braden. Is the intent to have 'living' branches for each major >> release (e.g. 2.6, 3.0) which contain tags for release candidates and >> minor >> revisions? So going forward we would have 2.6.x , 3.0.x, ... >> branches? >> >> -James Jong >> >> On Mar 21, 2013, at 10:36 AM, Braden Shepherdson > > >> wrote: >> >> > I meant to send an email about this last night. Here's the >> >(high-level) >> > process we'll need to follow for each of the repos. >> > >> > Step 0: This time only, delete the 'next' branch. We're not using >> them >> > anymore, and they'll just add confusion. >> > Step 1: Checkout and pull master. >> > Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) >> > Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) >> > Step 4: Push the branch and tag. >> > >> > NB: The branch is for the minor revision (ie. 2.6.x) not the point >> release >> > (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. >> and >> then >> > 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, >> just >> > adding more tags. >> > >> > Remember that commits always land in master first. Regression fixes >> should >> > be cherry-picked to 2.6.x after being committed to master. >> > >> > Braden >> > >> > >> > >> > >> > On Thu, Mar 21, 2013 at 10:17 AM, James Jong >> wrote: >> > >> >> Is the new release branching process for 2.6 posted somewhere? I >> >>didn't >> >> see it searching through the emails. >> >> >> >> -James Jong >> >> >> >> On Mar 20, 2013, at 1:37 PM, Braden Shepherdson < >> bra...@chromium.org> >> >> wrote: >> >> >> >>> My changes are in. >> >>> >> >>> >> >>> On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: >> >>> >> Alright sounds like we need to wait on those pull reqs. >> >> Braden, if you get it in time, great, otherwise, not a big deal. >> >> Related: can someone recap the newer release/branching/tagging >> approach >> >> we >> talked about at the face-to-face (and let's decide if we want to >> use >> it >> >> or >> not)? >> >> On 3/20/13 9:20 AM, "Shazron" wrote: >> >> > I'm trying to get CB-52 for FileTransfer upload/download and the >> > keyboardformaccessorybar re-fix in as well - also seeing if the >> > FileTransfer mobile-spec stuff works to test. Was planning on >> >pulling >> >> in >> > the iOS pull requests but may not have time, but it seems Andrew >> >is >> on >> >> it >> > already :) >> > >> > >> > On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson >> > wrote: >> > >> >> I'm working on rolling some of the plugin JS loading logic into >> >> cordova-js. >> >> If that makes this release then it will be possible to play with >> >> plugman >> >> without also needing bleeding-edge JS. Note that this logic >> >>won't be >> >> active >> >> if there are no plugins, so it shouldn't be a high-risk change >> to >> >> slide >> >> in >> >> before a release. >> >> >> >> >> >> On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve < >> agri...@chromium.org >> >>> wrote: >> >> >> >>> T
Re: tag 2.6.0rc1 soon?
Originally I thought it would be great to get it into the docs.cordova.iodocs, but then the audience is pretty small (committers) - in my opinion the wiki would be better for that. My 2 cents is the ContributorWorkflow ( http://wiki.apache.org/cordova/ContributorWorkflow) would be a better candidate for getting into cordova-docs -- we do want our general dev-users to contribute fixes, etc. Filing a bug should be part of the Contributing section as well: http://wiki.apache.org/cordova/ReportingBugs On Thu, Mar 21, 2013 at 11:36 AM, Braden Shepherdson wrote: > Yes, that's on my list of things to do. I'm making progress along that > list, but it's currently outrunning me. > > Do people like the idea of putting this doc into the docs.cordova.io docs? > Or do we prefer to keep contributor-related things in the wiki? If the > latter, it can wait, but if the former then I should probably commit it > very soon. > > Braden > > > On Thu, Mar 21, 2013 at 1:58 PM, Brian LeRoux wrote: > > > Braden also published this detailed guide for contributors on the topic: > > > > > > > https://googledrive.com/host/0B8sLcyOAEX-XUHAxNXhISE5rTTg/guide_contributing_index.md.html > > > > (Which I'm guessing will make its way into our docs proper?) > > > > > > On Thu, Mar 21, 2013 at 10:09 AM, Filip Maj wrote: > > > Alright folks, mobile-spec and cordova-js are tagged 2.6.0rc1, and the > > > 2.6.x branches on both those repos are now pushed up. Gogo release > mode! > > > > > > On 3/21/13 9:12 AM, "James Jong" wrote: > > > > > >>Nice. Thanks Michal. > > >> > > >>-James Jong > > >> > > >>On Mar 21, 2013, at 11:57 AM, Michal Mocny > wrote: > > >> > > >>> Yes, the intent is to have living branches. We may also cherry-pick > > >>> regressions back to more than just the current release. > > >>> > > >>> > > >>> On Thu, Mar 21, 2013 at 11:50 AM, James Jong > > >>>wrote: > > >>> > > Thanks Braden. Is the intent to have 'living' branches for each > major > > release (e.g. 2.6, 3.0) which contain tags for release candidates > and > > minor > > revisions? So going forward we would have 2.6.x , 3.0.x, ... > > branches? > > > > -James Jong > > > > On Mar 21, 2013, at 10:36 AM, Braden Shepherdson < > bra...@chromium.org > > > > > wrote: > > > > > I meant to send an email about this last night. Here's the > > >(high-level) > > > process we'll need to follow for each of the repos. > > > > > > Step 0: This time only, delete the 'next' branch. We're not using > > them > > > anymore, and they'll just add confusion. > > > Step 1: Checkout and pull master. > > > Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) > > > Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) > > > Step 4: Push the branch and tag. > > > > > > NB: The branch is for the minor revision (ie. 2.6.x) not the point > > release > > > (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. > > and > > then > > > 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, > > just > > > adding more tags. > > > > > > Remember that commits always land in master first. Regression fixes > > should > > > be cherry-picked to 2.6.x after being committed to master. > > > > > > Braden > > > > > > > > > > > > > > > On Thu, Mar 21, 2013 at 10:17 AM, James Jong > > > wrote: > > > > > >> Is the new release branching process for 2.6 posted somewhere? I > > >>didn't > > >> see it searching through the emails. > > >> > > >> -James Jong > > >> > > >> On Mar 20, 2013, at 1:37 PM, Braden Shepherdson < > > bra...@chromium.org> > > >> wrote: > > >> > > >>> My changes are in. > > >>> > > >>> > > >>> On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj > wrote: > > >>> > > Alright sounds like we need to wait on those pull reqs. > > > > Braden, if you get it in time, great, otherwise, not a big deal. > > > > Related: can someone recap the newer release/branching/tagging > > approach > > >> we > > talked about at the face-to-face (and let's decide if we want to > > use > > it > > >> or > > not)? > > > > On 3/20/13 9:20 AM, "Shazron" wrote: > > > > > I'm trying to get CB-52 for FileTransfer upload/download and > the > > > keyboardformaccessorybar re-fix in as well - also seeing if the > > > FileTransfer mobile-spec stuff works to test. Was planning on > > >pulling > > >> in > > > the iOS pull requests but may not have time, but it seems > Andrew > > >is > > on > > >> it > > > already :) > > > > > > > > > On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson > > > wrote: > > > > > >> I'm working on rolling some of the plugin JS loadi
Plugins, Apps, Tests and Samples
https://docs.google.com/document/d/1jcXrmmXR1dL3VsMymSxMYabDYvjgweZHX5dPmfizbgo/edit?usp=sharing The Google team spent over an hour debating various issues around this and packaging, and we've got some arguments, counterarguments, and proposed solutions in this doc. It's intended as a primer for issues we want to make decisions on during tomorrow's Hangout meeting. Please take a look and see what you think. Anyone with the link should be able to comment on it. Braden
Re: tag 2.6.0rc1 soon?
Yes, that's on my list of things to do. I'm making progress along that list, but it's currently outrunning me. Do people like the idea of putting this doc into the docs.cordova.io docs? Or do we prefer to keep contributor-related things in the wiki? If the latter, it can wait, but if the former then I should probably commit it very soon. Braden On Thu, Mar 21, 2013 at 1:58 PM, Brian LeRoux wrote: > Braden also published this detailed guide for contributors on the topic: > > > https://googledrive.com/host/0B8sLcyOAEX-XUHAxNXhISE5rTTg/guide_contributing_index.md.html > > (Which I'm guessing will make its way into our docs proper?) > > > On Thu, Mar 21, 2013 at 10:09 AM, Filip Maj wrote: > > Alright folks, mobile-spec and cordova-js are tagged 2.6.0rc1, and the > > 2.6.x branches on both those repos are now pushed up. Gogo release mode! > > > > On 3/21/13 9:12 AM, "James Jong" wrote: > > > >>Nice. Thanks Michal. > >> > >>-James Jong > >> > >>On Mar 21, 2013, at 11:57 AM, Michal Mocny wrote: > >> > >>> Yes, the intent is to have living branches. We may also cherry-pick > >>> regressions back to more than just the current release. > >>> > >>> > >>> On Thu, Mar 21, 2013 at 11:50 AM, James Jong > >>>wrote: > >>> > Thanks Braden. Is the intent to have 'living' branches for each major > release (e.g. 2.6, 3.0) which contain tags for release candidates and > minor > revisions? So going forward we would have 2.6.x , 3.0.x, ... > branches? > > -James Jong > > On Mar 21, 2013, at 10:36 AM, Braden Shepherdson > > wrote: > > > I meant to send an email about this last night. Here's the > >(high-level) > > process we'll need to follow for each of the repos. > > > > Step 0: This time only, delete the 'next' branch. We're not using > them > > anymore, and they'll just add confusion. > > Step 1: Checkout and pull master. > > Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) > > Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) > > Step 4: Push the branch and tag. > > > > NB: The branch is for the minor revision (ie. 2.6.x) not the point > release > > (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. > and > then > > 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, > just > > adding more tags. > > > > Remember that commits always land in master first. Regression fixes > should > > be cherry-picked to 2.6.x after being committed to master. > > > > Braden > > > > > > > > > > On Thu, Mar 21, 2013 at 10:17 AM, James Jong > wrote: > > > >> Is the new release branching process for 2.6 posted somewhere? I > >>didn't > >> see it searching through the emails. > >> > >> -James Jong > >> > >> On Mar 20, 2013, at 1:37 PM, Braden Shepherdson < > bra...@chromium.org> > >> wrote: > >> > >>> My changes are in. > >>> > >>> > >>> On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: > >>> > Alright sounds like we need to wait on those pull reqs. > > Braden, if you get it in time, great, otherwise, not a big deal. > > Related: can someone recap the newer release/branching/tagging > approach > >> we > talked about at the face-to-face (and let's decide if we want to > use > it > >> or > not)? > > On 3/20/13 9:20 AM, "Shazron" wrote: > > > I'm trying to get CB-52 for FileTransfer upload/download and the > > keyboardformaccessorybar re-fix in as well - also seeing if the > > FileTransfer mobile-spec stuff works to test. Was planning on > >pulling > >> in > > the iOS pull requests but may not have time, but it seems Andrew > >is > on > >> it > > already :) > > > > > > On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson > > wrote: > > > >> I'm working on rolling some of the plugin JS loading logic into > >> cordova-js. > >> If that makes this release then it will be possible to play with > >> plugman > >> without also needing bleeding-edge JS. Note that this logic > >>won't be > >> active > >> if there are no plugins, so it shouldn't be a high-risk change > to > >> slide > >> in > >> before a release. > >> > >> > >> On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve < > agri...@chromium.org > >>> wrote: > >> > >>> Time's feeling right for a release. > >>> > >>> I'm planning on going through pull requests today. Makes sense > >>>to > get > >> those > >>> all in before starting the release. > >>> > >>> > >>> On Wed, Mar 20, 2013 at 6:49 AM, James Jong >
Re: tag 2.6.0rc1 soon?
Braden also published this detailed guide for contributors on the topic: https://googledrive.com/host/0B8sLcyOAEX-XUHAxNXhISE5rTTg/guide_contributing_index.md.html (Which I'm guessing will make its way into our docs proper?) On Thu, Mar 21, 2013 at 10:09 AM, Filip Maj wrote: > Alright folks, mobile-spec and cordova-js are tagged 2.6.0rc1, and the > 2.6.x branches on both those repos are now pushed up. Gogo release mode! > > On 3/21/13 9:12 AM, "James Jong" wrote: > >>Nice. Thanks Michal. >> >>-James Jong >> >>On Mar 21, 2013, at 11:57 AM, Michal Mocny wrote: >> >>> Yes, the intent is to have living branches. We may also cherry-pick >>> regressions back to more than just the current release. >>> >>> >>> On Thu, Mar 21, 2013 at 11:50 AM, James Jong >>>wrote: >>> Thanks Braden. Is the intent to have 'living' branches for each major release (e.g. 2.6, 3.0) which contain tags for release candidates and minor revisions? So going forward we would have 2.6.x , 3.0.x, ... branches? -James Jong On Mar 21, 2013, at 10:36 AM, Braden Shepherdson wrote: > I meant to send an email about this last night. Here's the >(high-level) > process we'll need to follow for each of the repos. > > Step 0: This time only, delete the 'next' branch. We're not using them > anymore, and they'll just add confusion. > Step 1: Checkout and pull master. > Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) > Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) > Step 4: Push the branch and tag. > > NB: The branch is for the minor revision (ie. 2.6.x) not the point release > (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. and then > 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, just > adding more tags. > > Remember that commits always land in master first. Regression fixes should > be cherry-picked to 2.6.x after being committed to master. > > Braden > > > > > On Thu, Mar 21, 2013 at 10:17 AM, James Jong wrote: > >> Is the new release branching process for 2.6 posted somewhere? I >>didn't >> see it searching through the emails. >> >> -James Jong >> >> On Mar 20, 2013, at 1:37 PM, Braden Shepherdson >> wrote: >> >>> My changes are in. >>> >>> >>> On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: >>> Alright sounds like we need to wait on those pull reqs. Braden, if you get it in time, great, otherwise, not a big deal. Related: can someone recap the newer release/branching/tagging approach >> we talked about at the face-to-face (and let's decide if we want to use it >> or not)? On 3/20/13 9:20 AM, "Shazron" wrote: > I'm trying to get CB-52 for FileTransfer upload/download and the > keyboardformaccessorybar re-fix in as well - also seeing if the > FileTransfer mobile-spec stuff works to test. Was planning on >pulling >> in > the iOS pull requests but may not have time, but it seems Andrew >is on >> it > already :) > > > On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson > wrote: > >> I'm working on rolling some of the plugin JS loading logic into >> cordova-js. >> If that makes this release then it will be possible to play with >> plugman >> without also needing bleeding-edge JS. Note that this logic >>won't be >> active >> if there are no plugins, so it shouldn't be a high-risk change to >> slide >> in >> before a release. >> >> >> On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve < agri...@chromium.org >>> wrote: >> >>> Time's feeling right for a release. >>> >>> I'm planning on going through pull requests today. Makes sense >>>to get >> those >>> all in before starting the release. >>> >>> >>> On Wed, Mar 20, 2013 at 6:49 AM, James Jong >>> >> wrote: >>> A couple of items I'd like to see get into 2.6: 1) Lorin's EXIF camera implementation 2) adding prompt dialog to the Notification API (completed, just >> needs >> to be merged in) https://github.com/apache/cordova-docs/pull/24 https://github.com/apache/cordova-js/pull/21 https://github.com/apache/cordova-ios/pull/35 https://github.com/apache/cordova-android/pull/35 https://github.com/apache/cordova-mobile-spec/pull/13 -James Jong On Mar 19, 2013, at 6:46 PM, B
Re: tag 2.6.0rc1 soon?
Alright folks, mobile-spec and cordova-js are tagged 2.6.0rc1, and the 2.6.x branches on both those repos are now pushed up. Gogo release mode! On 3/21/13 9:12 AM, "James Jong" wrote: >Nice. Thanks Michal. > >-James Jong > >On Mar 21, 2013, at 11:57 AM, Michal Mocny wrote: > >> Yes, the intent is to have living branches. We may also cherry-pick >> regressions back to more than just the current release. >> >> >> On Thu, Mar 21, 2013 at 11:50 AM, James Jong >>wrote: >> >>> Thanks Braden. Is the intent to have 'living' branches for each major >>> release (e.g. 2.6, 3.0) which contain tags for release candidates and >>>minor >>> revisions? So going forward we would have 2.6.x , 3.0.x, ... branches? >>> >>> -James Jong >>> >>> On Mar 21, 2013, at 10:36 AM, Braden Shepherdson >>> wrote: >>> I meant to send an email about this last night. Here's the (high-level) process we'll need to follow for each of the repos. Step 0: This time only, delete the 'next' branch. We're not using them anymore, and they'll just add confusion. Step 1: Checkout and pull master. Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) Step 4: Push the branch and tag. NB: The branch is for the minor revision (ie. 2.6.x) not the point >>> release (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. and >>> then 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, just adding more tags. Remember that commits always land in master first. Regression fixes >>> should be cherry-picked to 2.6.x after being committed to master. Braden On Thu, Mar 21, 2013 at 10:17 AM, James Jong >>> wrote: > Is the new release branching process for 2.6 posted somewhere? I >didn't > see it searching through the emails. > > -James Jong > > On Mar 20, 2013, at 1:37 PM, Braden Shepherdson > wrote: > >> My changes are in. >> >> >> On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: >> >>> Alright sounds like we need to wait on those pull reqs. >>> >>> Braden, if you get it in time, great, otherwise, not a big deal. >>> >>> Related: can someone recap the newer release/branching/tagging >>> approach > we >>> talked about at the face-to-face (and let's decide if we want to >>>use >>> it > or >>> not)? >>> >>> On 3/20/13 9:20 AM, "Shazron" wrote: >>> I'm trying to get CB-52 for FileTransfer upload/download and the keyboardformaccessorybar re-fix in as well - also seeing if the FileTransfer mobile-spec stuff works to test. Was planning on pulling > in the iOS pull requests but may not have time, but it seems Andrew is >>> on > it already :) On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson wrote: > I'm working on rolling some of the plugin JS loading logic into > cordova-js. > If that makes this release then it will be possible to play with > plugman > without also needing bleeding-edge JS. Note that this logic >won't be > active > if there are no plugins, so it shouldn't be a high-risk change to > slide > in > before a release. > > > On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve < >>> agri...@chromium.org >> wrote: > >> Time's feeling right for a release. >> >> I'm planning on going through pull requests today. Makes sense >>to >>> get > those >> all in before starting the release. >> >> >> On Wed, Mar 20, 2013 at 6:49 AM, James Jong >> > wrote: >> >>> A couple of items I'd like to see get into 2.6: >>> 1) Lorin's EXIF camera implementation >>> >>> 2) adding prompt dialog to the Notification API (completed, >>>just > needs > to >>> be merged in) >>> https://github.com/apache/cordova-docs/pull/24 >>> https://github.com/apache/cordova-js/pull/21 >>> https://github.com/apache/cordova-ios/pull/35 >>> https://github.com/apache/cordova-android/pull/35 >>> https://github.com/apache/cordova-mobile-spec/pull/13 >>> >>> -James Jong >>> >>> On Mar 19, 2013, at 6:46 PM, Brian LeRoux wrote: >>> Ya braden put that huge thread on the list w/ the docs.. On Tue, Mar 19, 2013 at 3:22 PM, Filip Maj >>> wrote: > Haha have we even brought back the new method to the list >since > the >> F2F? > > On 3/19/13 3:21 PM, "Brian LeRoux" wrote: > >>
Re: tag 2.6.0rc1 soon?
Thanks for the summary Braden! On 3/21/13 7:36 AM, "Braden Shepherdson" wrote: >I meant to send an email about this last night. Here's the (high-level) >process we'll need to follow for each of the repos. > >Step 0: This time only, delete the 'next' branch. We're not using them >anymore, and they'll just add confusion. >Step 1: Checkout and pull master. >Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) >Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) >Step 4: Push the branch and tag. > >NB: The branch is for the minor revision (ie. 2.6.x) not the point release >(2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. and >then >2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, just >adding more tags. > >Remember that commits always land in master first. Regression fixes should >be cherry-picked to 2.6.x after being committed to master. > >Braden > > > > >On Thu, Mar 21, 2013 at 10:17 AM, James Jong wrote: > >> Is the new release branching process for 2.6 posted somewhere? I didn't >> see it searching through the emails. >> >> -James Jong >> >> On Mar 20, 2013, at 1:37 PM, Braden Shepherdson >> wrote: >> >> > My changes are in. >> > >> > >> > On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: >> > >> >> Alright sounds like we need to wait on those pull reqs. >> >> >> >> Braden, if you get it in time, great, otherwise, not a big deal. >> >> >> >> Related: can someone recap the newer release/branching/tagging >>approach >> we >> >> talked about at the face-to-face (and let's decide if we want to use >>it >> or >> >> not)? >> >> >> >> On 3/20/13 9:20 AM, "Shazron" wrote: >> >> >> >>> I'm trying to get CB-52 for FileTransfer upload/download and the >> >>> keyboardformaccessorybar re-fix in as well - also seeing if the >> >>> FileTransfer mobile-spec stuff works to test. Was planning on >>pulling >> in >> >>> the iOS pull requests but may not have time, but it seems Andrew is >>on >> it >> >>> already :) >> >>> >> >>> >> >>> On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson >> >>> wrote: >> >>> >> I'm working on rolling some of the plugin JS loading logic into >> cordova-js. >> If that makes this release then it will be possible to play with >> plugman >> without also needing bleeding-edge JS. Note that this logic won't >>be >> active >> if there are no plugins, so it shouldn't be a high-risk change to >> slide >> in >> before a release. >> >> >> On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve >>> > wrote: >> >> > Time's feeling right for a release. >> > >> > I'm planning on going through pull requests today. Makes sense to >>get >> those >> > all in before starting the release. >> > >> > >> > On Wed, Mar 20, 2013 at 6:49 AM, James Jong >> wrote: >> > >> >> A couple of items I'd like to see get into 2.6: >> >> 1) Lorin's EXIF camera implementation >> >> >> >> 2) adding prompt dialog to the Notification API (completed, just >> needs >> to >> >> be merged in) >> >> https://github.com/apache/cordova-docs/pull/24 >> >> https://github.com/apache/cordova-js/pull/21 >> >> https://github.com/apache/cordova-ios/pull/35 >> >> https://github.com/apache/cordova-android/pull/35 >> >> https://github.com/apache/cordova-mobile-spec/pull/13 >> >> >> >> -James Jong >> >> >> >> On Mar 19, 2013, at 6:46 PM, Brian LeRoux wrote: >> >> >> >>> Ya braden put that huge thread on the list w/ the docs.. >> >>> >> >>> On Tue, Mar 19, 2013 at 3:22 PM, Filip Maj >>wrote: >> Haha have we even brought back the new method to the list since >> the >> > F2F? >> >> On 3/19/13 3:21 PM, "Brian LeRoux" wrote: >> >> > Yes, lets give this new method a go. >> > >> > On Tue, Mar 19, 2013 at 1:24 PM, Filip Maj >> wrote: >> >> How we feeling for that? Are there any outstanding features >>out >> > there >> >> that >> >> are on the cusp of landing, or can we go into rc + test mode >> > soon-ish? >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >>
Re: Pull requests done
Sweet, I will kick off the tagging issues On 3/21/13 9:22 AM, "Shazron" wrote: >Thanks Andrew! >I've got new mobile-spec FileTransfer tests in for the new basic auth >upload/download plus the corresponding new deployed >cordova-filetransfer.jitsu.com script. There might be failures on some >platforms for these 2 new tests (WP7 comes to mind since it doesn't >support >window.btoa in JavaScript) > >I'd like to get some doc changes in for today (iOS / OS X) but I suppose >we >can get the release train running... > > >On Thu, Mar 21, 2013 at 2:00 AM, Xavier wrote: > >> > Noticed a cordova-js pull request for Windows >> >> If you are referring to "Windows build (CB-1667 and CB-2588)" [1], I'd >> like to clarify that it is about Windows as a development platform >> [2][3], not as a cordova platform >> >> [1] https://github.com/apache/cordova-js/pull/14 >> [2] https://issues.apache.org/jira/browse/CB-1667 >> [3] https://issues.apache.org/jira/browse/CB-2588 >> >> -Xavier >>
Re: Pull requests done
Thanks Andrew! I've got new mobile-spec FileTransfer tests in for the new basic auth upload/download plus the corresponding new deployed cordova-filetransfer.jitsu.com script. There might be failures on some platforms for these 2 new tests (WP7 comes to mind since it doesn't support window.btoa in JavaScript) I'd like to get some doc changes in for today (iOS / OS X) but I suppose we can get the release train running... On Thu, Mar 21, 2013 at 2:00 AM, Xavier wrote: > > Noticed a cordova-js pull request for Windows > > If you are referring to "Windows build (CB-1667 and CB-2588)" [1], I'd > like to clarify that it is about Windows as a development platform > [2][3], not as a cordova platform > > [1] https://github.com/apache/cordova-js/pull/14 > [2] https://issues.apache.org/jira/browse/CB-1667 > [3] https://issues.apache.org/jira/browse/CB-2588 > > -Xavier >
Re: tag 2.6.0rc1 soon?
Nice. Thanks Michal. -James Jong On Mar 21, 2013, at 11:57 AM, Michal Mocny wrote: > Yes, the intent is to have living branches. We may also cherry-pick > regressions back to more than just the current release. > > > On Thu, Mar 21, 2013 at 11:50 AM, James Jong wrote: > >> Thanks Braden. Is the intent to have 'living' branches for each major >> release (e.g. 2.6, 3.0) which contain tags for release candidates and minor >> revisions? So going forward we would have 2.6.x , 3.0.x, ... branches? >> >> -James Jong >> >> On Mar 21, 2013, at 10:36 AM, Braden Shepherdson >> wrote: >> >>> I meant to send an email about this last night. Here's the (high-level) >>> process we'll need to follow for each of the repos. >>> >>> Step 0: This time only, delete the 'next' branch. We're not using them >>> anymore, and they'll just add confusion. >>> Step 1: Checkout and pull master. >>> Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) >>> Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) >>> Step 4: Push the branch and tag. >>> >>> NB: The branch is for the minor revision (ie. 2.6.x) not the point >> release >>> (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. and >> then >>> 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, just >>> adding more tags. >>> >>> Remember that commits always land in master first. Regression fixes >> should >>> be cherry-picked to 2.6.x after being committed to master. >>> >>> Braden >>> >>> >>> >>> >>> On Thu, Mar 21, 2013 at 10:17 AM, James Jong >> wrote: >>> Is the new release branching process for 2.6 posted somewhere? I didn't see it searching through the emails. -James Jong On Mar 20, 2013, at 1:37 PM, Braden Shepherdson wrote: > My changes are in. > > > On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: > >> Alright sounds like we need to wait on those pull reqs. >> >> Braden, if you get it in time, great, otherwise, not a big deal. >> >> Related: can someone recap the newer release/branching/tagging >> approach we >> talked about at the face-to-face (and let's decide if we want to use >> it or >> not)? >> >> On 3/20/13 9:20 AM, "Shazron" wrote: >> >>> I'm trying to get CB-52 for FileTransfer upload/download and the >>> keyboardformaccessorybar re-fix in as well - also seeing if the >>> FileTransfer mobile-spec stuff works to test. Was planning on pulling in >>> the iOS pull requests but may not have time, but it seems Andrew is >> on it >>> already :) >>> >>> >>> On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson >>> wrote: >>> I'm working on rolling some of the plugin JS loading logic into cordova-js. If that makes this release then it will be possible to play with plugman without also needing bleeding-edge JS. Note that this logic won't be active if there are no plugins, so it shouldn't be a high-risk change to slide in before a release. On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve < >> agri...@chromium.org > wrote: > Time's feeling right for a release. > > I'm planning on going through pull requests today. Makes sense to >> get those > all in before starting the release. > > > On Wed, Mar 20, 2013 at 6:49 AM, James Jong wrote: > >> A couple of items I'd like to see get into 2.6: >> 1) Lorin's EXIF camera implementation >> >> 2) adding prompt dialog to the Notification API (completed, just needs to >> be merged in) >> https://github.com/apache/cordova-docs/pull/24 >> https://github.com/apache/cordova-js/pull/21 >> https://github.com/apache/cordova-ios/pull/35 >> https://github.com/apache/cordova-android/pull/35 >> https://github.com/apache/cordova-mobile-spec/pull/13 >> >> -James Jong >> >> On Mar 19, 2013, at 6:46 PM, Brian LeRoux wrote: >> >>> Ya braden put that huge thread on the list w/ the docs.. >>> >>> On Tue, Mar 19, 2013 at 3:22 PM, Filip Maj >> wrote: Haha have we even brought back the new method to the list since the > F2F? On 3/19/13 3:21 PM, "Brian LeRoux" wrote: > Yes, lets give this new method a go. > > On Tue, Mar 19, 2013 at 1:24 PM, Filip Maj wrote: >> How we feeling for that? Are there any outstanding features >> out > there >> that >> are on the cusp of landing, or can we go into rc + test mode > soon-ish? >> >> >> >
Re: tag 2.6.0rc1 soon?
Yes, the intent is to have living branches. We may also cherry-pick regressions back to more than just the current release. On Thu, Mar 21, 2013 at 11:50 AM, James Jong wrote: > Thanks Braden. Is the intent to have 'living' branches for each major > release (e.g. 2.6, 3.0) which contain tags for release candidates and minor > revisions? So going forward we would have 2.6.x , 3.0.x, ... branches? > > -James Jong > > On Mar 21, 2013, at 10:36 AM, Braden Shepherdson > wrote: > > > I meant to send an email about this last night. Here's the (high-level) > > process we'll need to follow for each of the repos. > > > > Step 0: This time only, delete the 'next' branch. We're not using them > > anymore, and they'll just add confusion. > > Step 1: Checkout and pull master. > > Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) > > Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) > > Step 4: Push the branch and tag. > > > > NB: The branch is for the minor revision (ie. 2.6.x) not the point > release > > (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. and > then > > 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, just > > adding more tags. > > > > Remember that commits always land in master first. Regression fixes > should > > be cherry-picked to 2.6.x after being committed to master. > > > > Braden > > > > > > > > > > On Thu, Mar 21, 2013 at 10:17 AM, James Jong > wrote: > > > >> Is the new release branching process for 2.6 posted somewhere? I didn't > >> see it searching through the emails. > >> > >> -James Jong > >> > >> On Mar 20, 2013, at 1:37 PM, Braden Shepherdson > >> wrote: > >> > >>> My changes are in. > >>> > >>> > >>> On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: > >>> > Alright sounds like we need to wait on those pull reqs. > > Braden, if you get it in time, great, otherwise, not a big deal. > > Related: can someone recap the newer release/branching/tagging > approach > >> we > talked about at the face-to-face (and let's decide if we want to use > it > >> or > not)? > > On 3/20/13 9:20 AM, "Shazron" wrote: > > > I'm trying to get CB-52 for FileTransfer upload/download and the > > keyboardformaccessorybar re-fix in as well - also seeing if the > > FileTransfer mobile-spec stuff works to test. Was planning on pulling > >> in > > the iOS pull requests but may not have time, but it seems Andrew is > on > >> it > > already :) > > > > > > On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson > > wrote: > > > >> I'm working on rolling some of the plugin JS loading logic into > >> cordova-js. > >> If that makes this release then it will be possible to play with > >> plugman > >> without also needing bleeding-edge JS. Note that this logic won't be > >> active > >> if there are no plugins, so it shouldn't be a high-risk change to > >> slide > >> in > >> before a release. > >> > >> > >> On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve < > agri...@chromium.org > >>> wrote: > >> > >>> Time's feeling right for a release. > >>> > >>> I'm planning on going through pull requests today. Makes sense to > get > >> those > >>> all in before starting the release. > >>> > >>> > >>> On Wed, Mar 20, 2013 at 6:49 AM, James Jong > >> wrote: > >>> > A couple of items I'd like to see get into 2.6: > 1) Lorin's EXIF camera implementation > > 2) adding prompt dialog to the Notification API (completed, just > >> needs > >> to > be merged in) > https://github.com/apache/cordova-docs/pull/24 > https://github.com/apache/cordova-js/pull/21 > https://github.com/apache/cordova-ios/pull/35 > https://github.com/apache/cordova-android/pull/35 > https://github.com/apache/cordova-mobile-spec/pull/13 > > -James Jong > > On Mar 19, 2013, at 6:46 PM, Brian LeRoux wrote: > > > Ya braden put that huge thread on the list w/ the docs.. > > > > On Tue, Mar 19, 2013 at 3:22 PM, Filip Maj > wrote: > >> Haha have we even brought back the new method to the list since > >> the > >>> F2F? > >> > >> On 3/19/13 3:21 PM, "Brian LeRoux" wrote: > >> > >>> Yes, lets give this new method a go. > >>> > >>> On Tue, Mar 19, 2013 at 1:24 PM, Filip Maj > >> wrote: > How we feeling for that? Are there any outstanding features > out > >>> there > that > are on the cusp of landing, or can we go into rc + test mode > >>> soon-ish? > > >> > > > >>> > >> > > > >> > >> > >
Re: tag 2.6.0rc1 soon?
Thanks Braden. Is the intent to have 'living' branches for each major release (e.g. 2.6, 3.0) which contain tags for release candidates and minor revisions? So going forward we would have 2.6.x , 3.0.x, ... branches? -James Jong On Mar 21, 2013, at 10:36 AM, Braden Shepherdson wrote: > I meant to send an email about this last night. Here's the (high-level) > process we'll need to follow for each of the repos. > > Step 0: This time only, delete the 'next' branch. We're not using them > anymore, and they'll just add confusion. > Step 1: Checkout and pull master. > Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) > Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) > Step 4: Push the branch and tag. > > NB: The branch is for the minor revision (ie. 2.6.x) not the point release > (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. and then > 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, just > adding more tags. > > Remember that commits always land in master first. Regression fixes should > be cherry-picked to 2.6.x after being committed to master. > > Braden > > > > > On Thu, Mar 21, 2013 at 10:17 AM, James Jong wrote: > >> Is the new release branching process for 2.6 posted somewhere? I didn't >> see it searching through the emails. >> >> -James Jong >> >> On Mar 20, 2013, at 1:37 PM, Braden Shepherdson >> wrote: >> >>> My changes are in. >>> >>> >>> On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: >>> Alright sounds like we need to wait on those pull reqs. Braden, if you get it in time, great, otherwise, not a big deal. Related: can someone recap the newer release/branching/tagging approach >> we talked about at the face-to-face (and let's decide if we want to use it >> or not)? On 3/20/13 9:20 AM, "Shazron" wrote: > I'm trying to get CB-52 for FileTransfer upload/download and the > keyboardformaccessorybar re-fix in as well - also seeing if the > FileTransfer mobile-spec stuff works to test. Was planning on pulling >> in > the iOS pull requests but may not have time, but it seems Andrew is on >> it > already :) > > > On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson > wrote: > >> I'm working on rolling some of the plugin JS loading logic into >> cordova-js. >> If that makes this release then it will be possible to play with >> plugman >> without also needing bleeding-edge JS. Note that this logic won't be >> active >> if there are no plugins, so it shouldn't be a high-risk change to >> slide >> in >> before a release. >> >> >> On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve >> wrote: >> >>> Time's feeling right for a release. >>> >>> I'm planning on going through pull requests today. Makes sense to get >> those >>> all in before starting the release. >>> >>> >>> On Wed, Mar 20, 2013 at 6:49 AM, James Jong >> wrote: >>> A couple of items I'd like to see get into 2.6: 1) Lorin's EXIF camera implementation 2) adding prompt dialog to the Notification API (completed, just >> needs >> to be merged in) https://github.com/apache/cordova-docs/pull/24 https://github.com/apache/cordova-js/pull/21 https://github.com/apache/cordova-ios/pull/35 https://github.com/apache/cordova-android/pull/35 https://github.com/apache/cordova-mobile-spec/pull/13 -James Jong On Mar 19, 2013, at 6:46 PM, Brian LeRoux wrote: > Ya braden put that huge thread on the list w/ the docs.. > > On Tue, Mar 19, 2013 at 3:22 PM, Filip Maj wrote: >> Haha have we even brought back the new method to the list since >> the >>> F2F? >> >> On 3/19/13 3:21 PM, "Brian LeRoux" wrote: >> >>> Yes, lets give this new method a go. >>> >>> On Tue, Mar 19, 2013 at 1:24 PM, Filip Maj >> wrote: How we feeling for that? Are there any outstanding features out >>> there that are on the cusp of landing, or can we go into rc + test mode >>> soon-ish? >> >>> >> >> >>
Re: tag 2.6.0rc1 soon?
I meant to send an email about this last night. Here's the (high-level) process we'll need to follow for each of the repos. Step 0: This time only, delete the 'next' branch. We're not using them anymore, and they'll just add confusion. Step 1: Checkout and pull master. Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) Step 4: Push the branch and tag. NB: The branch is for the minor revision (ie. 2.6.x) not the point release (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. and then 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, just adding more tags. Remember that commits always land in master first. Regression fixes should be cherry-picked to 2.6.x after being committed to master. Braden On Thu, Mar 21, 2013 at 10:17 AM, James Jong wrote: > Is the new release branching process for 2.6 posted somewhere? I didn't > see it searching through the emails. > > -James Jong > > On Mar 20, 2013, at 1:37 PM, Braden Shepherdson > wrote: > > > My changes are in. > > > > > > On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: > > > >> Alright sounds like we need to wait on those pull reqs. > >> > >> Braden, if you get it in time, great, otherwise, not a big deal. > >> > >> Related: can someone recap the newer release/branching/tagging approach > we > >> talked about at the face-to-face (and let's decide if we want to use it > or > >> not)? > >> > >> On 3/20/13 9:20 AM, "Shazron" wrote: > >> > >>> I'm trying to get CB-52 for FileTransfer upload/download and the > >>> keyboardformaccessorybar re-fix in as well - also seeing if the > >>> FileTransfer mobile-spec stuff works to test. Was planning on pulling > in > >>> the iOS pull requests but may not have time, but it seems Andrew is on > it > >>> already :) > >>> > >>> > >>> On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson > >>> wrote: > >>> > I'm working on rolling some of the plugin JS loading logic into > cordova-js. > If that makes this release then it will be possible to play with > plugman > without also needing bleeding-edge JS. Note that this logic won't be > active > if there are no plugins, so it shouldn't be a high-risk change to > slide > in > before a release. > > > On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve > wrote: > > > Time's feeling right for a release. > > > > I'm planning on going through pull requests today. Makes sense to get > those > > all in before starting the release. > > > > > > On Wed, Mar 20, 2013 at 6:49 AM, James Jong > wrote: > > > >> A couple of items I'd like to see get into 2.6: > >> 1) Lorin's EXIF camera implementation > >> > >> 2) adding prompt dialog to the Notification API (completed, just > needs > to > >> be merged in) > >> https://github.com/apache/cordova-docs/pull/24 > >> https://github.com/apache/cordova-js/pull/21 > >> https://github.com/apache/cordova-ios/pull/35 > >> https://github.com/apache/cordova-android/pull/35 > >> https://github.com/apache/cordova-mobile-spec/pull/13 > >> > >> -James Jong > >> > >> On Mar 19, 2013, at 6:46 PM, Brian LeRoux wrote: > >> > >>> Ya braden put that huge thread on the list w/ the docs.. > >>> > >>> On Tue, Mar 19, 2013 at 3:22 PM, Filip Maj wrote: > Haha have we even brought back the new method to the list since > the > > F2F? > > On 3/19/13 3:21 PM, "Brian LeRoux" wrote: > > > Yes, lets give this new method a go. > > > > On Tue, Mar 19, 2013 at 1:24 PM, Filip Maj > wrote: > >> How we feeling for that? Are there any outstanding features out > > there > >> that > >> are on the cusp of landing, or can we go into rc + test mode > > soon-ish? > >> > > >> > >> > > > > >> > >> > >
Re: tag 2.6.0rc1 soon?
Is the new release branching process for 2.6 posted somewhere? I didn't see it searching through the emails. -James Jong On Mar 20, 2013, at 1:37 PM, Braden Shepherdson wrote: > My changes are in. > > > On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: > >> Alright sounds like we need to wait on those pull reqs. >> >> Braden, if you get it in time, great, otherwise, not a big deal. >> >> Related: can someone recap the newer release/branching/tagging approach we >> talked about at the face-to-face (and let's decide if we want to use it or >> not)? >> >> On 3/20/13 9:20 AM, "Shazron" wrote: >> >>> I'm trying to get CB-52 for FileTransfer upload/download and the >>> keyboardformaccessorybar re-fix in as well - also seeing if the >>> FileTransfer mobile-spec stuff works to test. Was planning on pulling in >>> the iOS pull requests but may not have time, but it seems Andrew is on it >>> already :) >>> >>> >>> On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson >>> wrote: >>> I'm working on rolling some of the plugin JS loading logic into cordova-js. If that makes this release then it will be possible to play with plugman without also needing bleeding-edge JS. Note that this logic won't be active if there are no plugins, so it shouldn't be a high-risk change to slide in before a release. On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve wrote: > Time's feeling right for a release. > > I'm planning on going through pull requests today. Makes sense to get those > all in before starting the release. > > > On Wed, Mar 20, 2013 at 6:49 AM, James Jong wrote: > >> A couple of items I'd like to see get into 2.6: >> 1) Lorin's EXIF camera implementation >> >> 2) adding prompt dialog to the Notification API (completed, just needs to >> be merged in) >> https://github.com/apache/cordova-docs/pull/24 >> https://github.com/apache/cordova-js/pull/21 >> https://github.com/apache/cordova-ios/pull/35 >> https://github.com/apache/cordova-android/pull/35 >> https://github.com/apache/cordova-mobile-spec/pull/13 >> >> -James Jong >> >> On Mar 19, 2013, at 6:46 PM, Brian LeRoux wrote: >> >>> Ya braden put that huge thread on the list w/ the docs.. >>> >>> On Tue, Mar 19, 2013 at 3:22 PM, Filip Maj wrote: Haha have we even brought back the new method to the list since the > F2F? On 3/19/13 3:21 PM, "Brian LeRoux" wrote: > Yes, lets give this new method a go. > > On Tue, Mar 19, 2013 at 1:24 PM, Filip Maj wrote: >> How we feeling for that? Are there any outstanding features out > there >> that >> are on the cusp of landing, or can we go into rc + test mode > soon-ish? >> >> >> > >> >>
Re: Pull requests done
> Noticed a cordova-js pull request for Windows If you are referring to "Windows build (CB-1667 and CB-2588)" [1], I'd like to clarify that it is about Windows as a development platform [2][3], not as a cordova platform [1] https://github.com/apache/cordova-js/pull/14 [2] https://issues.apache.org/jira/browse/CB-1667 [3] https://issues.apache.org/jira/browse/CB-2588 -Xavier
Re: Platform-level command line scripts ;)
renaming stuff is easy. Does it make sense to log without running? or does log also launch? where? Sounds to me like logging is an option attached to a run command. What is the point of cleaning if you're not going to build right after? trying to free up hard drive space? anal much? or is clean just a build option? The current state of WP7+WP8 Every WP7 and WP8 cordova project that you create with the create script, or with the template has a debug and an emulate command. debug: builds and runs on the attached device. emulate : builds and runs on the first emulator, starting it if it was not already running @purplecabbage risingj.com On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes wrote: > I liked the idea you mentioned earlier with having one wrapper script, > that way there is one entry point for the given commands for the needed > functionality. Then it doesn't matter what underlying scripts actually do > the work. > > Then our only focus would be on the commands and not so much the name of > the scripts. > > > On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve > wrote: > > > I really like Anis's suggestion of just four scripts. What's the > motivation > > for having many scripts? Having fewer will dramatically reduce copy & > paste > > bugs. It will also aid discoverability (since you'll get --help instead > of > > just "ls" and infer from the name what they do). > > > > > > On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj wrote: > > > > > Ya ya ya we're all on agreement on this specific issue. The underlying > > > platform scripts can be used regardless of whether you're using > > > cordova-cli or not. > > > > > > On 3/20/13 3:51 PM, "Anis KADRI" wrote: > > > > > > >On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes > > wrote: > > > > > > > >> I know that sounds > > > >> like a lot > > > >> of scripts but we're building them for the cordova-cli to use, so i > > > >>like > > > >> the idea of breaking > > > >> them out so each script does a *very specific* task with as > > > >>little-to-no > > > >> > > > > > > > >No we're not. cordova-cli is a cool tool that people can use but it > > should > > > >not be the only way of building Cordova apps in my opinion. > > > > > > > > >
