Re: Documentation update to previous version
Thanks Shaz! I was away for JSConf, so another contributor handled the cordova-docs release for 2.8.0. Michael On Wed, Jun 19, 2013 at 1:46 PM, Shazron wrote: > This commit that was tagged 2.8.0: > > https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=1d2fdf5a3344a554136c505b162d1931e878daad > > Does not occur in branch 2.8.x: > > https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/heads/2.8.x > > Nor does the tagged commit occur in master(!) - the commit there has a > different sha1: > > https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=ef7308be2a3d6cb38a8c699766c59e951fd2b514 > > So, it was tagged in some unknown branch, not sure where... > > So I'm cherry picking: > > https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=ef7308be2a3d6cb38a8c699766c59e951fd2b514 > > Into the 2.8.x branch, and tagging that 2.8.0 > > > > > On Wed, Jun 19, 2013 at 1:40 PM, Shazron wrote: > > > Rhetorical question of course I am fixing this... > > > > > > On Wed, Jun 19, 2013 at 1:36 PM, Shazron wrote: > > > >> I noticed in cordova-docs, the 2.8.0 tag was tagged in a commit on > >> master, but not in the 2.8.x branch. Furthermore, the commit that was > >> tagged is not even in the 2.8.x branch. Do I fix this? > >> > >> > >> On Wed, Jun 19, 2013 at 11:51 AM, Shazron wrote: > >> > >>> Makes sense. I'll cherry-pick my changes to the relevant branches. > >>> > >>> > >>> On Wed, Jun 19, 2013 at 11:45 AM, Michael Brooks < > >>> mich...@michaelbrooks.ca> wrote: > >>> > Hey guys, > > There is no denying that the release branch practice is a little odd > for > cordova-docs. This is because the cordova-docs repository versions > everything by directory (a legacy approach that we will someday shift > away > from). > > I'll hunt down the release wiki article and update it, but here is the > rundown of the release details: > > Generating the documentation: > --- > The documentation is always generated from the master branch on the > HEAD > commit. > The markdown is rendered to HTML as a one-to-one mapping of the /docs/ > directory. > Files can be merged together by defining the merge order in > /docs/language/version/config.json > > Updating the documentation for an upcoming release: > --- > Always commit into master. > When documenting an upcoming release, update the documentation under > docs/en/edge/ > > Updating the documentation for a previous release: > --- > Always commit into master. > Update the specific version (e.g. docs/en/2.7.0/) > Also update each newer version until edge (e.g. docs/en/2.8.0/ and > docs/en/edge) > Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) > Update each release branch tag to point to your new commit > > All in all, the release branches are a ceremony that are only used by > coho. > However, when cordova-docs is revamped to not include all versions, > then > the tags and release branches will make a lot more sense. > Additionally, > we'll be happy to have accurate tags for older versions. > > Michael > > > On Tue, Jun 18, 2013 at 9:34 AM, Shazron wrote: > > > Yeah I'm interested in the flow as well. I think we published > everything > > again in older releases, not sure if we are still doing that going > forward > > > > > > On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard > wrote: > > > > > On Jun 17, 2013, at 6:21 PM, Shazron wrote: > > > > > > > Should I bother? I know they will go in edge. There are a couple > of > > > issues: > > > > https://issues.apache.org/jira/browse/CB-3753 > > > > https://issues.apache.org/jira/browse/CB-3752 > > > > > > > > Basically it's weird since if I added it to the 2.8.0 folder, > it's not > > in > > > > the 2.8.x branch, but is in master... > > > > > > > > So for older version updates, I don't bother with the older > branches, > > > yes? > > > > Just master and the older folders > > > > > > @mwbrooks, when the docs get published to the web at the end of > the > > > release, does just edge or all version folders get published? > > > > > > If all folders get published, then correct, no need to commit to > old > > > branches, as all users that browse the docs online will see your > change > > in > > > the 2.8.0 folder (which is somewhat confusingly [but cleverly] > from > > > master)… unless we ever build a patch release which doesn't seem > to > > happen, > > > with the possible exception of 2.9.x. > > > > >>> > >>> > >> > > >
Re: Media API, DataResource, and empty URLs
Agree that we should make Media() an error, but we don't want to change the semantics of relative URLs for APIs without proper deprecation. On Thu, Jun 20, 2013 at 12:00 AM, Ian Clelland wrote: > On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve > wrote: > > > "null" could be interpreted as a relative URL I think. The current > handling > > of relative URLs by plugins is sadly plugin-specific. > > > > Isn't that one of the things that DataResource is supposed to standardize? > > > The string "null" is certainly a relative URL, and all plugins should > interpret that as one. The empty string is a relative url as well. (See the > 'image src=""' problem). DataResource should probably handle relative URLs; > that seems like a deficiency if it can't. > > We shouldn't be representing the JavaScript null value as "null", or as "", > though. I don't think there's any rational reason to support new Media() as > a construct. Media is fairly clearly documented as taking two required > parameters, and two optional ones. I don't think Media() makes sense -- it > doesn't give you a useful object. The calls to Media() are likely just in > mobile-spec, and we should clean those up. > > > > > > > > On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson > >wrote: > > > > > The automated tests for Media frequently call new Media() with no URL, > > > which sends a null to the "create" action. In the past, this got turned > > > into the string "null" in Java, which was handled as a file named > "null" > > > that didn't exist, and nothing crashed. > > > > > > DataResource is fine with the files not existing, but it's not fine > with > > > "null" as a filename since it neither has a URL scheme nor is it an > > > absolute path. > > > > > > Is there a reason why new Media() should work rather than throwing > > > IllegalArgumentExceptions for trying to read files with relative paths? > > > Should I detect and gracefully handle null being given as the media URL > > in > > > Javascript? In Java? Should I instead change the mobile-spec tests to > use > > > "file:///dummy" or similar? > > > > > > Braden > > > > > >
Re: 2.9.0rc1 this coming monday??
Okay, made more sense to just update the existing command to handle this. For next time, we can just re-tag the JS and re-run: ./cordova-coho/coho prepare-release-branch --version 2.9.0rc1 and it will update all the JS snapshots on both master and the release branch. On Wed, Jun 19, 2013 at 10:34 PM, Andrew Grieve wrote: > Late to the game here, but to re-tag JS: > > ./cordova-coho/coho tag-release --version 2.9.0rc1 -r js > > To update JS snapshots in all repos, coho can't handle that yet. I think > I'll break updating of JS out into its own command so that we can address > this usecase. > > > > On Wed, Jun 19, 2013 at 6:05 PM, Shazron wrote: > >> Never mind me dum dum. Thanks Jesse >> >> >> On Wed, Jun 19, 2013 at 2:52 PM, Shazron wrote: >> >> > Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, >> > the version in the .js header is still 2.7.0 - checked the VERSION file >> is >> > correct. >> > >> > >> > On Wed, Jun 19, 2013 at 2:50 PM, Jesse wrote: >> > >> >> Ha, my next question. I want to know too ... >> >> I have pushed to master and cherry-pick'd into 2.9.x >> >> >> >> My change just added support for a case where XHR was permitted, but >> there >> >> wasn't a json file. It then attempts the script injection to load a >> .js >> >> plugins file, instead of just giving up. This would likely be the >> case in >> >> iOS on/after 3.0.0 or whenever we stop generating both a js+json files. >> >> >> >> @purplecabbage >> >> risingj.com >> >> >> >> >> >> On Wed, Jun 19, 2013 at 2:40 PM, Shazron wrote: >> >> >> >> > Ok so how do we update the JS on all platforms now? coho? >> >> > >> >> > >> >> > On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj wrote: >> >> > >> >> > > Works on WP7 and Jesse reports it working on WP8. >> >> > > >> >> > > I am merging back into master and retagging JS shortly. >> >> > > >> >> > > On 6/19/13 2:03 PM, "Jesse" wrote: >> >> > > >> >> > > >I am testing on windows as well. I think I have a change, give >> me a >> >> few >> >> > > >minutes to verify. >> >> > > > >> >> > > >@purplecabbage >> >> > > >risingj.com >> >> > > > >> >> > > > >> >> > > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: >> >> > > > >> >> > > >> Confirmed it works on android iOS and bb10. >> >> > > >> >> >> > > >> Am gonna help Benn work through and make sure it's working on >> >> windows >> >> > > >> phone * >> >> > > >> >> >> > > >> On 6/19/13 1:24 PM, "Jesse" wrote: >> >> > > >> >> >> > > >> >Yeah, to Braden's point while it may work, the behavior is not >> >> > > >>guaranteed, >> >> > > >> >and could break later. Also the contents of the file differ >> >> between >> >> > > >>the 2 >> >> > > >> >methods. >> >> > > >> > >> >> > > >> >Also discussing this in a quick chat with Fil, I think the best >> >> > > >>approach >> >> > > >> >is: >> >> > > >> >1. Plugman generates both files, a js and a json >> >> > > >> >2. cordova.js attempts XHR, and catches the exception, in which >> >> case >> >> > it >> >> > > >> >continues on to a script injection attempt. >> >> > > >> > >> >> > > >> > >> >> > > >> >@purplecabbage >> >> > > >> >risingj.com >> >> > > >> > >> >> > > >> > >> >> > > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson >> >> > > >> >wrote: >> >> > > >> > >> >> > > >> >> JSON files are not valid Javascript code. >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj >> >> wrote: >> >> > > >> >> >> >> > > >> >> > Can we not have the script tag point to the json file? Does >> >> the >> >> > > >> >>extension >> >> > > >> >> > have to be .js? >> >> > > >> >> > >> >> > > >> >> > On 6/19/13 12:10 PM, "Jesse" >> wrote: >> >> > > >> >> > >> >> > > >> >> > >I was just going to suggest outputting both. That works >> for >> >> me. >> >> > > >> >> > > >> >> > > >> >> > >@purplecabbage >> >> > > >> >> > >risingj.com >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >> >> > > >> >> > >wrote: >> >> > > >> >> > > >> >> > > >> >> > >> Follow-up thought: No reason why we can't generate both >> >> > > >> >> > >>cordova_plugins.js >> >> > > >> >> > >> and cordova_plugins.json for a while. >> >> > > >> >> > >> >> >> > > >> >> > >> Braden >> >> > > >> >> > >> >> >> > > >> >> > >> >> >> > > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < >> >> > > >> >> > bra...@chromium.org >> >> > > >> >> > >> >wrote: >> >> > > >> >> > >> >> >> > > >> >> > >> > Hm. This will of course require changing the name of >> the >> >> > file >> >> > > >> >> Plugman >> >> > > >> >> > >> > generates, and it will mean users need to be very >> >> careful to >> >> > > >>be >> >> > > >> >> using >> >> > > >> >> > >> > sufficiently new plugman and cordova-js. >> >> > > >> >> > >> > >> >> > > >> >> > >> > In short: only the upgrade path for users bothers me >> >> about >> >> > > >>this; >> >> > > >> >>the >> >> > > >> >> > >> > change to use a .js file and
Re: Media API, DataResource, and empty URLs
On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve wrote: > "null" could be interpreted as a relative URL I think. The current handling > of relative URLs by plugins is sadly plugin-specific. > Isn't that one of the things that DataResource is supposed to standardize? The string "null" is certainly a relative URL, and all plugins should interpret that as one. The empty string is a relative url as well. (See the 'image src=""' problem). DataResource should probably handle relative URLs; that seems like a deficiency if it can't. We shouldn't be representing the JavaScript null value as "null", or as "", though. I don't think there's any rational reason to support new Media() as a construct. Media is fairly clearly documented as taking two required parameters, and two optional ones. I don't think Media() makes sense -- it doesn't give you a useful object. The calls to Media() are likely just in mobile-spec, and we should clean those up. > > On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson >wrote: > > > The automated tests for Media frequently call new Media() with no URL, > > which sends a null to the "create" action. In the past, this got turned > > into the string "null" in Java, which was handled as a file named "null" > > that didn't exist, and nothing crashed. > > > > DataResource is fine with the files not existing, but it's not fine with > > "null" as a filename since it neither has a URL scheme nor is it an > > absolute path. > > > > Is there a reason why new Media() should work rather than throwing > > IllegalArgumentExceptions for trying to read files with relative paths? > > Should I detect and gracefully handle null being given as the media URL > in > > Javascript? In Java? Should I instead change the mobile-spec tests to use > > "file:///dummy" or similar? > > > > Braden > > >
Re: Media API, DataResource, and empty URLs
"null" could be interpreted as a relative URL I think. The current handling of relative URLs by plugins is sadly plugin-specific. On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson wrote: > The automated tests for Media frequently call new Media() with no URL, > which sends a null to the "create" action. In the past, this got turned > into the string "null" in Java, which was handled as a file named "null" > that didn't exist, and nothing crashed. > > DataResource is fine with the files not existing, but it's not fine with > "null" as a filename since it neither has a URL scheme nor is it an > absolute path. > > Is there a reason why new Media() should work rather than throwing > IllegalArgumentExceptions for trying to read files with relative paths? > Should I detect and gracefully handle null being given as the media URL in > Javascript? In Java? Should I instead change the mobile-spec tests to use > "file:///dummy" or similar? > > Braden >
Re: 2.9.0rc1 this coming monday??
Late to the game here, but to re-tag JS: ./cordova-coho/coho tag-release --version 2.9.0rc1 -r js To update JS snapshots in all repos, coho can't handle that yet. I think I'll break updating of JS out into its own command so that we can address this usecase. On Wed, Jun 19, 2013 at 6:05 PM, Shazron wrote: > Never mind me dum dum. Thanks Jesse > > > On Wed, Jun 19, 2013 at 2:52 PM, Shazron wrote: > > > Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, > > the version in the .js header is still 2.7.0 - checked the VERSION file > is > > correct. > > > > > > On Wed, Jun 19, 2013 at 2:50 PM, Jesse wrote: > > > >> Ha, my next question. I want to know too ... > >> I have pushed to master and cherry-pick'd into 2.9.x > >> > >> My change just added support for a case where XHR was permitted, but > there > >> wasn't a json file. It then attempts the script injection to load a .js > >> plugins file, instead of just giving up. This would likely be the case > in > >> iOS on/after 3.0.0 or whenever we stop generating both a js+json files. > >> > >> @purplecabbage > >> risingj.com > >> > >> > >> On Wed, Jun 19, 2013 at 2:40 PM, Shazron wrote: > >> > >> > Ok so how do we update the JS on all platforms now? coho? > >> > > >> > > >> > On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj wrote: > >> > > >> > > Works on WP7 and Jesse reports it working on WP8. > >> > > > >> > > I am merging back into master and retagging JS shortly. > >> > > > >> > > On 6/19/13 2:03 PM, "Jesse" wrote: > >> > > > >> > > >I am testing on windows as well. I think I have a change, give me > a > >> few > >> > > >minutes to verify. > >> > > > > >> > > >@purplecabbage > >> > > >risingj.com > >> > > > > >> > > > > >> > > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: > >> > > > > >> > > >> Confirmed it works on android iOS and bb10. > >> > > >> > >> > > >> Am gonna help Benn work through and make sure it's working on > >> windows > >> > > >> phone * > >> > > >> > >> > > >> On 6/19/13 1:24 PM, "Jesse" wrote: > >> > > >> > >> > > >> >Yeah, to Braden's point while it may work, the behavior is not > >> > > >>guaranteed, > >> > > >> >and could break later. Also the contents of the file differ > >> between > >> > > >>the 2 > >> > > >> >methods. > >> > > >> > > >> > > >> >Also discussing this in a quick chat with Fil, I think the best > >> > > >>approach > >> > > >> >is: > >> > > >> >1. Plugman generates both files, a js and a json > >> > > >> >2. cordova.js attempts XHR, and catches the exception, in which > >> case > >> > it > >> > > >> >continues on to a script injection attempt. > >> > > >> > > >> > > >> > > >> > > >> >@purplecabbage > >> > > >> >risingj.com > >> > > >> > > >> > > >> > > >> > > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson > >> > > >> >wrote: > >> > > >> > > >> > > >> >> JSON files are not valid Javascript code. > >> > > >> >> > >> > > >> >> > >> > > >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj > >> wrote: > >> > > >> >> > >> > > >> >> > Can we not have the script tag point to the json file? Does > >> the > >> > > >> >>extension > >> > > >> >> > have to be .js? > >> > > >> >> > > >> > > >> >> > On 6/19/13 12:10 PM, "Jesse" > wrote: > >> > > >> >> > > >> > > >> >> > >I was just going to suggest outputting both. That works > for > >> me. > >> > > >> >> > > > >> > > >> >> > >@purplecabbage > >> > > >> >> > >risingj.com > >> > > >> >> > > > >> > > >> >> > > > >> > > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson > >> > > >> >> > >wrote: > >> > > >> >> > > > >> > > >> >> > >> Follow-up thought: No reason why we can't generate both > >> > > >> >> > >>cordova_plugins.js > >> > > >> >> > >> and cordova_plugins.json for a while. > >> > > >> >> > >> > >> > > >> >> > >> Braden > >> > > >> >> > >> > >> > > >> >> > >> > >> > > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < > >> > > >> >> > bra...@chromium.org > >> > > >> >> > >> >wrote: > >> > > >> >> > >> > >> > > >> >> > >> > Hm. This will of course require changing the name of > the > >> > file > >> > > >> >> Plugman > >> > > >> >> > >> > generates, and it will mean users need to be very > >> careful to > >> > > >>be > >> > > >> >> using > >> > > >> >> > >> > sufficiently new plugman and cordova-js. > >> > > >> >> > >> > > >> > > >> >> > >> > In short: only the upgrade path for users bothers me > >> about > >> > > >>this; > >> > > >> >>the > >> > > >> >> > >> > change to use a .js file and
Re: cordova-ios/iphone/beep.wav
Looking at the issue, I don't think it needed a beep.wav, which makes me think this was accidentally checked in On Wed, Jun 19, 2013 at 4:00 PM, Jesse wrote: > If you need a wav file for the beep, I have composed a CC licensed file > here: > > https://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=tree;f=common/resources;h=a9558f417570ee1793d34be30b81291750597153;hb=HEAD > > > @purplecabbage > risingj.com > > > On Wed, Jun 19, 2013 at 3:30 PM, Shazron wrote: > > > Ian, was this file supposed to be checked in? > > https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;h=4c63589 > > > > https://issues.apache.org/jira/browse/CB-2840 > > > > Ran Apache RAT and noticed that one. > > >
Re: cordova-ios/iphone/beep.wav
If you need a wav file for the beep, I have composed a CC licensed file here: https://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=tree;f=common/resources;h=a9558f417570ee1793d34be30b81291750597153;hb=HEAD @purplecabbage risingj.com On Wed, Jun 19, 2013 at 3:30 PM, Shazron wrote: > Ian, was this file supposed to be checked in? > https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;h=4c63589 > > https://issues.apache.org/jira/browse/CB-2840 > > Ran Apache RAT and noticed that one. >
cordova-ios/iphone/beep.wav
Ian, was this file supposed to be checked in? https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;h=4c63589 https://issues.apache.org/jira/browse/CB-2840 Ran Apache RAT and noticed that one.
Re: 2.9.0rc1 this coming monday??
Never mind me dum dum. Thanks Jesse On Wed, Jun 19, 2013 at 2:52 PM, Shazron wrote: > Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, > the version in the .js header is still 2.7.0 - checked the VERSION file is > correct. > > > On Wed, Jun 19, 2013 at 2:50 PM, Jesse wrote: > >> Ha, my next question. I want to know too ... >> I have pushed to master and cherry-pick'd into 2.9.x >> >> My change just added support for a case where XHR was permitted, but there >> wasn't a json file. It then attempts the script injection to load a .js >> plugins file, instead of just giving up. This would likely be the case in >> iOS on/after 3.0.0 or whenever we stop generating both a js+json files. >> >> @purplecabbage >> risingj.com >> >> >> On Wed, Jun 19, 2013 at 2:40 PM, Shazron wrote: >> >> > Ok so how do we update the JS on all platforms now? coho? >> > >> > >> > On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj wrote: >> > >> > > Works on WP7 and Jesse reports it working on WP8. >> > > >> > > I am merging back into master and retagging JS shortly. >> > > >> > > On 6/19/13 2:03 PM, "Jesse" wrote: >> > > >> > > >I am testing on windows as well. I think I have a change, give me a >> few >> > > >minutes to verify. >> > > > >> > > >@purplecabbage >> > > >risingj.com >> > > > >> > > > >> > > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: >> > > > >> > > >> Confirmed it works on android iOS and bb10. >> > > >> >> > > >> Am gonna help Benn work through and make sure it's working on >> windows >> > > >> phone * >> > > >> >> > > >> On 6/19/13 1:24 PM, "Jesse" wrote: >> > > >> >> > > >> >Yeah, to Braden's point while it may work, the behavior is not >> > > >>guaranteed, >> > > >> >and could break later. Also the contents of the file differ >> between >> > > >>the 2 >> > > >> >methods. >> > > >> > >> > > >> >Also discussing this in a quick chat with Fil, I think the best >> > > >>approach >> > > >> >is: >> > > >> >1. Plugman generates both files, a js and a json >> > > >> >2. cordova.js attempts XHR, and catches the exception, in which >> case >> > it >> > > >> >continues on to a script injection attempt. >> > > >> > >> > > >> > >> > > >> >@purplecabbage >> > > >> >risingj.com >> > > >> > >> > > >> > >> > > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson >> > > >> >wrote: >> > > >> > >> > > >> >> JSON files are not valid Javascript code. >> > > >> >> >> > > >> >> >> > > >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj >> wrote: >> > > >> >> >> > > >> >> > Can we not have the script tag point to the json file? Does >> the >> > > >> >>extension >> > > >> >> > have to be .js? >> > > >> >> > >> > > >> >> > On 6/19/13 12:10 PM, "Jesse" wrote: >> > > >> >> > >> > > >> >> > >I was just going to suggest outputting both. That works for >> me. >> > > >> >> > > >> > > >> >> > >@purplecabbage >> > > >> >> > >risingj.com >> > > >> >> > > >> > > >> >> > > >> > > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >> > > >> >> > >wrote: >> > > >> >> > > >> > > >> >> > >> Follow-up thought: No reason why we can't generate both >> > > >> >> > >>cordova_plugins.js >> > > >> >> > >> and cordova_plugins.json for a while. >> > > >> >> > >> >> > > >> >> > >> Braden >> > > >> >> > >> >> > > >> >> > >> >> > > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < >> > > >> >> > bra...@chromium.org >> > > >> >> > >> >wrote: >> > > >> >> > >> >> > > >> >> > >> > Hm. This will of course require changing the name of the >> > file >> > > >> >> Plugman >> > > >> >> > >> > generates, and it will mean users need to be very >> careful to >> > > >>be >> > > >> >> using >> > > >> >> > >> > sufficiently new plugman and cordova-js. >> > > >> >> > >> > >> > > >> >> > >> > In short: only the upgrade path for users bothers me >> about >> > > >>this; >> > > >> >>the >> > > >> >> > >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
Its the magical "computeGitVersion" in jakefile. Apparently it boils down: $ git describe --tags --long 2.7.0rc1-94-g002f33d Not sure why that returns 2.7.0, nor why we use that instead of VERSION. I suggest moving forward and manually tagging. On 6/19/13 2:52 PM, "Shazron" wrote: >Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, >the >version in the .js header is still 2.7.0 - checked the VERSION file is >correct. > > >On Wed, Jun 19, 2013 at 2:50 PM, Jesse wrote: > >> Ha, my next question. I want to know too ... >> I have pushed to master and cherry-pick'd into 2.9.x >> >> My change just added support for a case where XHR was permitted, but >>there >> wasn't a json file. It then attempts the script injection to load a .js >> plugins file, instead of just giving up. This would likely be the case >>in >> iOS on/after 3.0.0 or whenever we stop generating both a js+json files. >> >> @purplecabbage >> risingj.com >> >> >> On Wed, Jun 19, 2013 at 2:40 PM, Shazron wrote: >> >> > Ok so how do we update the JS on all platforms now? coho? >> > >> > >> > On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj wrote: >> > >> > > Works on WP7 and Jesse reports it working on WP8. >> > > >> > > I am merging back into master and retagging JS shortly. >> > > >> > > On 6/19/13 2:03 PM, "Jesse" wrote: >> > > >> > > >I am testing on windows as well. I think I have a change, give me >>a >> few >> > > >minutes to verify. >> > > > >> > > >@purplecabbage >> > > >risingj.com >> > > > >> > > > >> > > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: >> > > > >> > > >> Confirmed it works on android iOS and bb10. >> > > >> >> > > >> Am gonna help Benn work through and make sure it's working on >> windows >> > > >> phone * >> > > >> >> > > >> On 6/19/13 1:24 PM, "Jesse" wrote: >> > > >> >> > > >> >Yeah, to Braden's point while it may work, the behavior is not >> > > >>guaranteed, >> > > >> >and could break later. Also the contents of the file differ >>between >> > > >>the 2 >> > > >> >methods. >> > > >> > >> > > >> >Also discussing this in a quick chat with Fil, I think the best >> > > >>approach >> > > >> >is: >> > > >> >1. Plugman generates both files, a js and a json >> > > >> >2. cordova.js attempts XHR, and catches the exception, in which >> case >> > it >> > > >> >continues on to a script injection attempt. >> > > >> > >> > > >> > >> > > >> >@purplecabbage >> > > >> >risingj.com >> > > >> > >> > > >> > >> > > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson >> > > >> >wrote: >> > > >> > >> > > >> >> JSON files are not valid Javascript code. >> > > >> >> >> > > >> >> >> > > >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj >> wrote: >> > > >> >> >> > > >> >> > Can we not have the script tag point to the json file? Does >>the >> > > >> >>extension >> > > >> >> > have to be .js? >> > > >> >> > >> > > >> >> > On 6/19/13 12:10 PM, "Jesse" >>wrote: >> > > >> >> > >> > > >> >> > >I was just going to suggest outputting both. That works >>for >> me. >> > > >> >> > > >> > > >> >> > >@purplecabbage >> > > >> >> > >risingj.com >> > > >> >> > > >> > > >> >> > > >> > > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >> > > >> >> > >wrote: >> > > >> >> > > >> > > >> >> > >> Follow-up thought: No reason why we can't generate both >> > > >> >> > >>cordova_plugins.js >> > > >> >> > >> and cordova_plugins.json for a while. >> > > >> >> > >> >> > > >> >> > >> Braden >> > > >> >> > >> >> > > >> >> > >> >> > > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < >> > > >> >> > bra...@chromium.org >> > > >> >> > >> >wrote: >> > > >> >> > >> >> > > >> >> > >> > Hm. This will of course require changing the name of >>the >> > file >> > > >> >> Plugman >> > > >> >> > >> > generates, and it will mean users need to be very >>careful >> to >> > > >>be >> > > >> >> using >> > > >> >> > >> > sufficiently new plugman and cordova-js. >> > > >> >> > >> > >> > > >> >> > >> > In short: only the upgrade path for users bothers me >>about >> > > >>this; >> > > >> >>the >> > > >> >> > >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
Just re-tagged, test and fly! I am now getting : // Platform: windowsphone // 2.9.0rc1-0-g002f33d @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:52 PM, Shazron wrote: > Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, the > version in the .js header is still 2.7.0 - checked the VERSION file is > correct. > > > On Wed, Jun 19, 2013 at 2:50 PM, Jesse wrote: > > > Ha, my next question. I want to know too ... > > I have pushed to master and cherry-pick'd into 2.9.x > > > > My change just added support for a case where XHR was permitted, but > there > > wasn't a json file. It then attempts the script injection to load a .js > > plugins file, instead of just giving up. This would likely be the case > in > > iOS on/after 3.0.0 or whenever we stop generating both a js+json files. > > > > @purplecabbage > > risingj.com > > > > > > On Wed, Jun 19, 2013 at 2:40 PM, Shazron wrote: > > > > > Ok so how do we update the JS on all platforms now? coho? > > > > > > > > > On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj wrote: > > > > > > > Works on WP7 and Jesse reports it working on WP8. > > > > > > > > I am merging back into master and retagging JS shortly. > > > > > > > > On 6/19/13 2:03 PM, "Jesse" wrote: > > > > > > > > >I am testing on windows as well. I think I have a change, give me a > > few > > > > >minutes to verify. > > > > > > > > > >@purplecabbage > > > > >risingj.com > > > > > > > > > > > > > > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: > > > > > > > > > >> Confirmed it works on android iOS and bb10. > > > > >> > > > > >> Am gonna help Benn work through and make sure it's working on > > windows > > > > >> phone * > > > > >> > > > > >> On 6/19/13 1:24 PM, "Jesse" wrote: > > > > >> > > > > >> >Yeah, to Braden's point while it may work, the behavior is not > > > > >>guaranteed, > > > > >> >and could break later. Also the contents of the file differ > between > > > > >>the 2 > > > > >> >methods. > > > > >> > > > > > >> >Also discussing this in a quick chat with Fil, I think the best > > > > >>approach > > > > >> >is: > > > > >> >1. Plugman generates both files, a js and a json > > > > >> >2. cordova.js attempts XHR, and catches the exception, in which > > case > > > it > > > > >> >continues on to a script injection attempt. > > > > >> > > > > > >> > > > > > >> >@purplecabbage > > > > >> >risingj.com > > > > >> > > > > > >> > > > > > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson > > > > >> >wrote: > > > > >> > > > > > >> >> JSON files are not valid Javascript code. > > > > >> >> > > > > >> >> > > > > >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj > > wrote: > > > > >> >> > > > > >> >> > Can we not have the script tag point to the json file? Does > the > > > > >> >>extension > > > > >> >> > have to be .js? > > > > >> >> > > > > > >> >> > On 6/19/13 12:10 PM, "Jesse" > wrote: > > > > >> >> > > > > > >> >> > >I was just going to suggest outputting both. That works for > > me. > > > > >> >> > > > > > > >> >> > >@purplecabbage > > > > >> >> > >risingj.com > > > > >> >> > > > > > > >> >> > > > > > > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson > > > > >> >> > >wrote: > > > > >> >> > > > > > > >> >> > >> Follow-up thought: No reason why we can't generate both > > > > >> >> > >>cordova_plugins.js > > > > >> >> > >> and cordova_plugins.json for a while. > > > > >> >> > >> > > > > >> >> > >> Braden > > > > >> >> > >> > > > > >> >> > >> > > > > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < > > > > >> >> > bra...@chromium.org > > > > >> >> > >> >wrote: > > > > >> >> > >> > > > > >> >> > >> > Hm. This will of course require changing the name of the > > > file > > > > >> >> Plugman > > > > >> >> > >> > generates, and it will mean users need to be very > careful > > to > > > > >>be > > > > >> >> using > > > > >> >> > >> > sufficiently new plugman and cordova-js. > > > > >> >> > >> > > > > > >> >> > >> > In short: only the upgrade path for users bothers me > about > > > > >>this; > > > > >> >>the > > > > >> >> > >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
Tag it the ol' fashioned way, then. Not sure why we need magic to do `git tag 2.9.0rc1 && git push --tags apache 2.9.x` On 6/19/13 2:50 PM, "Jesse" wrote: >Ha, my next question. I want to know too ... >I have pushed to master and cherry-pick'd into 2.9.x > >My change just added support for a case where XHR was permitted, but there >wasn't a json file. It then attempts the script injection to load a .js >plugins file, instead of just giving up. This would likely be the case in >iOS on/after 3.0.0 or whenever we stop generating both a js+json files. > >@purplecabbage >risingj.com > > >On Wed, Jun 19, 2013 at 2:40 PM, Shazron wrote: > >> Ok so how do we update the JS on all platforms now? coho? >> >> >> On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj wrote: >> >> > Works on WP7 and Jesse reports it working on WP8. >> > >> > I am merging back into master and retagging JS shortly. >> > >> > On 6/19/13 2:03 PM, "Jesse" wrote: >> > >> > >I am testing on windows as well. I think I have a change, give me a >>few >> > >minutes to verify. >> > > >> > >@purplecabbage >> > >risingj.com >> > > >> > > >> > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: >> > > >> > >> Confirmed it works on android iOS and bb10. >> > >> >> > >> Am gonna help Benn work through and make sure it's working on >>windows >> > >> phone * >> > >> >> > >> On 6/19/13 1:24 PM, "Jesse" wrote: >> > >> >> > >> >Yeah, to Braden's point while it may work, the behavior is not >> > >>guaranteed, >> > >> >and could break later. Also the contents of the file differ >>between >> > >>the 2 >> > >> >methods. >> > >> > >> > >> >Also discussing this in a quick chat with Fil, I think the best >> > >>approach >> > >> >is: >> > >> >1. Plugman generates both files, a js and a json >> > >> >2. cordova.js attempts XHR, and catches the exception, in which >>case >> it >> > >> >continues on to a script injection attempt. >> > >> > >> > >> > >> > >> >@purplecabbage >> > >> >risingj.com >> > >> > >> > >> > >> > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson >> > >> >wrote: >> > >> > >> > >> >> JSON files are not valid Javascript code. >> > >> >> >> > >> >> >> > >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj >>wrote: >> > >> >> >> > >> >> > Can we not have the script tag point to the json file? Does >>the >> > >> >>extension >> > >> >> > have to be .js? >> > >> >> > >> > >> >> > On 6/19/13 12:10 PM, "Jesse" wrote: >> > >> >> > >> > >> >> > >I was just going to suggest outputting both. That works for >>me. >> > >> >> > > >> > >> >> > >@purplecabbage >> > >> >> > >risingj.com >> > >> >> > > >> > >> >> > > >> > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >> > >> >> > >wrote: >> > >> >> > > >> > >> >> > >> Follow-up thought: No reason why we can't generate both >> > >> >> > >>cordova_plugins.js >> > >> >> > >> and cordova_plugins.json for a while. >> > >> >> > >> >> > >> >> > >> Braden >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < >> > >> >> > bra...@chromium.org >> > >> >> > >> >wrote: >> > >> >> > >> >> > >> >> > >> > Hm. This will of course require changing the name of the >> file >> > >> >> Plugman >> > >> >> > >> > generates, and it will mean users need to be very >>careful to >> > >>be >> > >> >> using >> > >> >> > >> > sufficiently new plugman and cordova-js. >> > >> >> > >> > >> > >> >> > >> > In short: only the upgrade path for users bothers me >>about >> > >>this; >> > >> >>the >> > >> >> > >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
Yeah I'm stalled on this one. If I run jake on cordova-js 2.9.x branch, the version in the .js header is still 2.7.0 - checked the VERSION file is correct. On Wed, Jun 19, 2013 at 2:50 PM, Jesse wrote: > Ha, my next question. I want to know too ... > I have pushed to master and cherry-pick'd into 2.9.x > > My change just added support for a case where XHR was permitted, but there > wasn't a json file. It then attempts the script injection to load a .js > plugins file, instead of just giving up. This would likely be the case in > iOS on/after 3.0.0 or whenever we stop generating both a js+json files. > > @purplecabbage > risingj.com > > > On Wed, Jun 19, 2013 at 2:40 PM, Shazron wrote: > > > Ok so how do we update the JS on all platforms now? coho? > > > > > > On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj wrote: > > > > > Works on WP7 and Jesse reports it working on WP8. > > > > > > I am merging back into master and retagging JS shortly. > > > > > > On 6/19/13 2:03 PM, "Jesse" wrote: > > > > > > >I am testing on windows as well. I think I have a change, give me a > few > > > >minutes to verify. > > > > > > > >@purplecabbage > > > >risingj.com > > > > > > > > > > > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: > > > > > > > >> Confirmed it works on android iOS and bb10. > > > >> > > > >> Am gonna help Benn work through and make sure it's working on > windows > > > >> phone * > > > >> > > > >> On 6/19/13 1:24 PM, "Jesse" wrote: > > > >> > > > >> >Yeah, to Braden's point while it may work, the behavior is not > > > >>guaranteed, > > > >> >and could break later. Also the contents of the file differ between > > > >>the 2 > > > >> >methods. > > > >> > > > > >> >Also discussing this in a quick chat with Fil, I think the best > > > >>approach > > > >> >is: > > > >> >1. Plugman generates both files, a js and a json > > > >> >2. cordova.js attempts XHR, and catches the exception, in which > case > > it > > > >> >continues on to a script injection attempt. > > > >> > > > > >> > > > > >> >@purplecabbage > > > >> >risingj.com > > > >> > > > > >> > > > > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson > > > >> >wrote: > > > >> > > > > >> >> JSON files are not valid Javascript code. > > > >> >> > > > >> >> > > > >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj > wrote: > > > >> >> > > > >> >> > Can we not have the script tag point to the json file? Does the > > > >> >>extension > > > >> >> > have to be .js? > > > >> >> > > > > >> >> > On 6/19/13 12:10 PM, "Jesse" wrote: > > > >> >> > > > > >> >> > >I was just going to suggest outputting both. That works for > me. > > > >> >> > > > > > >> >> > >@purplecabbage > > > >> >> > >risingj.com > > > >> >> > > > > > >> >> > > > > > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson > > > >> >> > >wrote: > > > >> >> > > > > > >> >> > >> Follow-up thought: No reason why we can't generate both > > > >> >> > >>cordova_plugins.js > > > >> >> > >> and cordova_plugins.json for a while. > > > >> >> > >> > > > >> >> > >> Braden > > > >> >> > >> > > > >> >> > >> > > > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < > > > >> >> > bra...@chromium.org > > > >> >> > >> >wrote: > > > >> >> > >> > > > >> >> > >> > Hm. This will of course require changing the name of the > > file > > > >> >> Plugman > > > >> >> > >> > generates, and it will mean users need to be very careful > to > > > >>be > > > >> >> using > > > >> >> > >> > sufficiently new plugman and cordova-js. > > > >> >> > >> > > > > >> >> > >> > In short: only the upgrade path for users bothers me about > > > >>this; > > > >> >>the > > > >> >> > >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
Ha, my next question. I want to know too ... I have pushed to master and cherry-pick'd into 2.9.x My change just added support for a case where XHR was permitted, but there wasn't a json file. It then attempts the script injection to load a .js plugins file, instead of just giving up. This would likely be the case in iOS on/after 3.0.0 or whenever we stop generating both a js+json files. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 2:40 PM, Shazron wrote: > Ok so how do we update the JS on all platforms now? coho? > > > On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj wrote: > > > Works on WP7 and Jesse reports it working on WP8. > > > > I am merging back into master and retagging JS shortly. > > > > On 6/19/13 2:03 PM, "Jesse" wrote: > > > > >I am testing on windows as well. I think I have a change, give me a few > > >minutes to verify. > > > > > >@purplecabbage > > >risingj.com > > > > > > > > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: > > > > > >> Confirmed it works on android iOS and bb10. > > >> > > >> Am gonna help Benn work through and make sure it's working on windows > > >> phone * > > >> > > >> On 6/19/13 1:24 PM, "Jesse" wrote: > > >> > > >> >Yeah, to Braden's point while it may work, the behavior is not > > >>guaranteed, > > >> >and could break later. Also the contents of the file differ between > > >>the 2 > > >> >methods. > > >> > > > >> >Also discussing this in a quick chat with Fil, I think the best > > >>approach > > >> >is: > > >> >1. Plugman generates both files, a js and a json > > >> >2. cordova.js attempts XHR, and catches the exception, in which case > it > > >> >continues on to a script injection attempt. > > >> > > > >> > > > >> >@purplecabbage > > >> >risingj.com > > >> > > > >> > > > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson > > >> >wrote: > > >> > > > >> >> JSON files are not valid Javascript code. > > >> >> > > >> >> > > >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj wrote: > > >> >> > > >> >> > Can we not have the script tag point to the json file? Does the > > >> >>extension > > >> >> > have to be .js? > > >> >> > > > >> >> > On 6/19/13 12:10 PM, "Jesse" wrote: > > >> >> > > > >> >> > >I was just going to suggest outputting both. That works for me. > > >> >> > > > > >> >> > >@purplecabbage > > >> >> > >risingj.com > > >> >> > > > > >> >> > > > > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson > > >> >> > >wrote: > > >> >> > > > > >> >> > >> Follow-up thought: No reason why we can't generate both > > >> >> > >>cordova_plugins.js > > >> >> > >> and cordova_plugins.json for a while. > > >> >> > >> > > >> >> > >> Braden > > >> >> > >> > > >> >> > >> > > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < > > >> >> > bra...@chromium.org > > >> >> > >> >wrote: > > >> >> > >> > > >> >> > >> > Hm. This will of course require changing the name of the > file > > >> >> Plugman > > >> >> > >> > generates, and it will mean users need to be very careful to > > >>be > > >> >> using > > >> >> > >> > sufficiently new plugman and cordova-js. > > >> >> > >> > > > >> >> > >> > In short: only the upgrade path for users bothers me about > > >>this; > > >> >>the > > >> >> > >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
Ok so how do we update the JS on all platforms now? coho? On Wed, Jun 19, 2013 at 2:19 PM, Filip Maj wrote: > Works on WP7 and Jesse reports it working on WP8. > > I am merging back into master and retagging JS shortly. > > On 6/19/13 2:03 PM, "Jesse" wrote: > > >I am testing on windows as well. I think I have a change, give me a few > >minutes to verify. > > > >@purplecabbage > >risingj.com > > > > > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: > > > >> Confirmed it works on android iOS and bb10. > >> > >> Am gonna help Benn work through and make sure it's working on windows > >> phone * > >> > >> On 6/19/13 1:24 PM, "Jesse" wrote: > >> > >> >Yeah, to Braden's point while it may work, the behavior is not > >>guaranteed, > >> >and could break later. Also the contents of the file differ between > >>the 2 > >> >methods. > >> > > >> >Also discussing this in a quick chat with Fil, I think the best > >>approach > >> >is: > >> >1. Plugman generates both files, a js and a json > >> >2. cordova.js attempts XHR, and catches the exception, in which case it > >> >continues on to a script injection attempt. > >> > > >> > > >> >@purplecabbage > >> >risingj.com > >> > > >> > > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson > >> >wrote: > >> > > >> >> JSON files are not valid Javascript code. > >> >> > >> >> > >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj wrote: > >> >> > >> >> > Can we not have the script tag point to the json file? Does the > >> >>extension > >> >> > have to be .js? > >> >> > > >> >> > On 6/19/13 12:10 PM, "Jesse" wrote: > >> >> > > >> >> > >I was just going to suggest outputting both. That works for me. > >> >> > > > >> >> > >@purplecabbage > >> >> > >risingj.com > >> >> > > > >> >> > > > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson > >> >> > >wrote: > >> >> > > > >> >> > >> Follow-up thought: No reason why we can't generate both > >> >> > >>cordova_plugins.js > >> >> > >> and cordova_plugins.json for a while. > >> >> > >> > >> >> > >> Braden > >> >> > >> > >> >> > >> > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < > >> >> > bra...@chromium.org > >> >> > >> >wrote: > >> >> > >> > >> >> > >> > Hm. This will of course require changing the name of the file > >> >> Plugman > >> >> > >> > generates, and it will mean users need to be very careful to > >>be > >> >> using > >> >> > >> > sufficiently new plugman and cordova-js. > >> >> > >> > > >> >> > >> > In short: only the upgrade path for users bothers me about > >>this; > >> >>the > >> >> > >> > change to use a .js file and
Re: BB10 bundling of node.js
Plugman and cordova-cli both require a minimum 0.9.9 node. See the "engines" and "engineStrict" flags in package.json for the two repos. engineStrict when set to true will force npm to make sure the user's version of node adheres to what is listed under the "engines" prop. On 6/19/13 1:15 PM, "Gord Tanner" wrote: >Still a -1, cordova (and all it's projects) should use the globally >installed version of node. > >If someone needs multiple versions of node the should probably use nvm [1] >to manage it. IMHO this is a user problem and not something we should >magically solve via bundled copies of node or hardcoded paths to specific >versions of node. > >I agree we should have a version of node we support, it just needs to be >consistent and common across all of our tools and require the user to have >that version range in their path. > >[1] - https://github.com/creationix/nvm > > >On Wed, Jun 19, 2013 at 3:57 PM, Bryan Higgins >wrote: > >> For 3.0 will there still be a ZIP file released by Apache? Will the >> instructions be download the latest version of node then run "npm >>install >> -g "? >> >> My assumption was the individual project templates will continue to work >> independently of CLI. >> >> Also, keep in mind that CLI invokes BB via shell scripts which in turn >>call >> node. So for environments where people need different versions of node >> installed, invoking CLI with an alternate node version will cause BB to >>be >> invoked via the globally installed version. Perhaps that is an edge >>case, >> but it's still something that needs to be supported by allowing them to >> configure node path for BB. >> >> >> On Wed, Jun 19, 2013 at 3:30 PM, Gord Tanner wrote: >> >> > I would expect they would have a supported node version when they >>type: >> > >> > "npm install cordova" >> > >> > which would do any version checks in the package.json [1] for >>supported >> > node versions >> > >> > [1] - >> > >> > >> >>https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f= >>package.json;hb=HEAD >> > >> > >> > On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins > > >wrote: >> > >> > > So for Cordova 3.0 in general, users will be required to >>pre-install a >> > > minimum version of node globally? >> > > >> > > We have had issues where upgrading node breaks stuff. I'd like to >>avoid >> > > that and give users flexibility with their own system configuration. >> > > >> > > >> > > On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner >> wrote: >> > > >> > > > -1 >> > > > >> > > > I would rather we just use the system version of node which would >>be >> > the >> > > > same version as the CLI. I can't think of any reason a specific >> > platform >> > > > (aka BlackBerry) would need a special version of a common >>dependency. >> > > > >> > > > Also I don't think you can bundle binaries in an apache release. >> > > > >> > > > >> > > > On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins < >> > bhigg...@blackberry.com >> > > > >wrote: >> > > > >> > > > > I'd like to reopen the topic of bundling node js into the >> blackberry >> > > > > platform. >> > > > > >> > > > > I have personally gotten feedback from users of errors which >>were >> > > caused >> > > > by >> > > > > node version inconsistencies. We have since updated the >>check_req >> > > script >> > > > to >> > > > > test for the minimum version of node we require, but that is >>not an >> > > ideal >> > > > > solution since users may need a different node version installed >> > > globally >> > > > > for other software. >> > > > > >> > > > > At a minimum, I'd like to give users the option to point to an >> > > alternate >> > > > > version of node. I have logged a JIRA issue for that. [1] >> > > > > >> > > > > What I'd prefer to do, is bundle the node binaries into the >> > > distribution. >> > > > > That would completely eliminate the dependency. Users would only >> need >> > > to >> > > > > worry about setting up the native SDK. >> > > > > >> > > > > We already do this in the WebWorks SDK [2] >> > > > > >> > > > > I'm interested how the community feels about this. Are there any >> > > > licensing >> > > > > concerns in Apache hosting binaries without source? >> > > > > >> > > > > [1] https://issues.apache.org/jira/browse/CB-3798 >> > > > > [2] >> > > > > >> > > > > >> > > > >> > > >> > >> >>https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_pa >>rty/node >> > > > > >> > > > >> > > >> > >>
Re: 2.9.0rc1 this coming monday??
Works on WP7 and Jesse reports it working on WP8. I am merging back into master and retagging JS shortly. On 6/19/13 2:03 PM, "Jesse" wrote: >I am testing on windows as well. I think I have a change, give me a few >minutes to verify. > >@purplecabbage >risingj.com > > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: > >> Confirmed it works on android iOS and bb10. >> >> Am gonna help Benn work through and make sure it's working on windows >> phone * >> >> On 6/19/13 1:24 PM, "Jesse" wrote: >> >> >Yeah, to Braden's point while it may work, the behavior is not >>guaranteed, >> >and could break later. Also the contents of the file differ between >>the 2 >> >methods. >> > >> >Also discussing this in a quick chat with Fil, I think the best >>approach >> >is: >> >1. Plugman generates both files, a js and a json >> >2. cordova.js attempts XHR, and catches the exception, in which case it >> >continues on to a script injection attempt. >> > >> > >> >@purplecabbage >> >risingj.com >> > >> > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson >> >wrote: >> > >> >> JSON files are not valid Javascript code. >> >> >> >> >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj wrote: >> >> >> >> > Can we not have the script tag point to the json file? Does the >> >>extension >> >> > have to be .js? >> >> > >> >> > On 6/19/13 12:10 PM, "Jesse" wrote: >> >> > >> >> > >I was just going to suggest outputting both. That works for me. >> >> > > >> >> > >@purplecabbage >> >> > >risingj.com >> >> > > >> >> > > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >> >> > >wrote: >> >> > > >> >> > >> Follow-up thought: No reason why we can't generate both >> >> > >>cordova_plugins.js >> >> > >> and cordova_plugins.json for a while. >> >> > >> >> >> > >> Braden >> >> > >> >> >> > >> >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < >> >> > bra...@chromium.org >> >> > >> >wrote: >> >> > >> >> >> > >> > Hm. This will of course require changing the name of the file >> >> Plugman >> >> > >> > generates, and it will mean users need to be very careful to >>be >> >> using >> >> > >> > sufficiently new plugman and cordova-js. >> >> > >> > >> >> > >> > In short: only the upgrade path for users bothers me about >>this; >> >>the >> >> > >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
Benn and I just tested the pl branch of cordova-js on Windows Phone 7, works well. We are gonna test on WP8 now too. On 6/19/13 2:03 PM, "Jesse" wrote: >I am testing on windows as well. I think I have a change, give me a few >minutes to verify. > >@purplecabbage >risingj.com > > >On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: > >> Confirmed it works on android iOS and bb10. >> >> Am gonna help Benn work through and make sure it's working on windows >> phone * >> >> On 6/19/13 1:24 PM, "Jesse" wrote: >> >> >Yeah, to Braden's point while it may work, the behavior is not >>guaranteed, >> >and could break later. Also the contents of the file differ between >>the 2 >> >methods. >> > >> >Also discussing this in a quick chat with Fil, I think the best >>approach >> >is: >> >1. Plugman generates both files, a js and a json >> >2. cordova.js attempts XHR, and catches the exception, in which case it >> >continues on to a script injection attempt. >> > >> > >> >@purplecabbage >> >risingj.com >> > >> > >> >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson >> >wrote: >> > >> >> JSON files are not valid Javascript code. >> >> >> >> >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj wrote: >> >> >> >> > Can we not have the script tag point to the json file? Does the >> >>extension >> >> > have to be .js? >> >> > >> >> > On 6/19/13 12:10 PM, "Jesse" wrote: >> >> > >> >> > >I was just going to suggest outputting both. That works for me. >> >> > > >> >> > >@purplecabbage >> >> > >risingj.com >> >> > > >> >> > > >> >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >> >> > >wrote: >> >> > > >> >> > >> Follow-up thought: No reason why we can't generate both >> >> > >>cordova_plugins.js >> >> > >> and cordova_plugins.json for a while. >> >> > >> >> >> > >> Braden >> >> > >> >> >> > >> >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < >> >> > bra...@chromium.org >> >> > >> >wrote: >> >> > >> >> >> > >> > Hm. This will of course require changing the name of the file >> >> Plugman >> >> > >> > generates, and it will mean users need to be very careful to >>be >> >> using >> >> > >> > sufficiently new plugman and cordova-js. >> >> > >> > >> >> > >> > In short: only the upgrade path for users bothers me about >>this; >> >>the >> >> > >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
I am testing on windows as well. I think I have a change, give me a few minutes to verify. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:54 PM, Filip Maj wrote: > Confirmed it works on android iOS and bb10. > > Am gonna help Benn work through and make sure it's working on windows > phone * > > On 6/19/13 1:24 PM, "Jesse" wrote: > > >Yeah, to Braden's point while it may work, the behavior is not guaranteed, > >and could break later. Also the contents of the file differ between the 2 > >methods. > > > >Also discussing this in a quick chat with Fil, I think the best approach > >is: > >1. Plugman generates both files, a js and a json > >2. cordova.js attempts XHR, and catches the exception, in which case it > >continues on to a script injection attempt. > > > > > >@purplecabbage > >risingj.com > > > > > >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson > >wrote: > > > >> JSON files are not valid Javascript code. > >> > >> > >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj wrote: > >> > >> > Can we not have the script tag point to the json file? Does the > >>extension > >> > have to be .js? > >> > > >> > On 6/19/13 12:10 PM, "Jesse" wrote: > >> > > >> > >I was just going to suggest outputting both. That works for me. > >> > > > >> > >@purplecabbage > >> > >risingj.com > >> > > > >> > > > >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson > >> > >wrote: > >> > > > >> > >> Follow-up thought: No reason why we can't generate both > >> > >>cordova_plugins.js > >> > >> and cordova_plugins.json for a while. > >> > >> > >> > >> Braden > >> > >> > >> > >> > >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < > >> > bra...@chromium.org > >> > >> >wrote: > >> > >> > >> > >> > Hm. This will of course require changing the name of the file > >> Plugman > >> > >> > generates, and it will mean users need to be very careful to be > >> using > >> > >> > sufficiently new plugman and cordova-js. > >> > >> > > >> > >> > In short: only the upgrade path for users bothers me about this; > >>the > >> > >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
Confirmed it works on android iOS and bb10. Am gonna help Benn work through and make sure it's working on windows phone * On 6/19/13 1:24 PM, "Jesse" wrote: >Yeah, to Braden's point while it may work, the behavior is not guaranteed, >and could break later. Also the contents of the file differ between the 2 >methods. > >Also discussing this in a quick chat with Fil, I think the best approach >is: >1. Plugman generates both files, a js and a json >2. cordova.js attempts XHR, and catches the exception, in which case it >continues on to a script injection attempt. > > >@purplecabbage >risingj.com > > >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson >wrote: > >> JSON files are not valid Javascript code. >> >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj wrote: >> >> > Can we not have the script tag point to the json file? Does the >>extension >> > have to be .js? >> > >> > On 6/19/13 12:10 PM, "Jesse" wrote: >> > >> > >I was just going to suggest outputting both. That works for me. >> > > >> > >@purplecabbage >> > >risingj.com >> > > >> > > >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >> > >wrote: >> > > >> > >> Follow-up thought: No reason why we can't generate both >> > >>cordova_plugins.js >> > >> and cordova_plugins.json for a while. >> > >> >> > >> Braden >> > >> >> > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < >> > bra...@chromium.org >> > >> >wrote: >> > >> >> > >> > Hm. This will of course require changing the name of the file >> Plugman >> > >> > generates, and it will mean users need to be very careful to be >> using >> > >> > sufficiently new plugman and cordova-js. >> > >> > >> > >> > In short: only the upgrade path for users bothers me about this; >>the >> > >> > change to use a .js file and
Re: Documentation update to previous version
This commit that was tagged 2.8.0: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=1d2fdf5a3344a554136c505b162d1931e878daad Does not occur in branch 2.8.x: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/heads/2.8.x Nor does the tagged commit occur in master(!) - the commit there has a different sha1: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=ef7308be2a3d6cb38a8c699766c59e951fd2b514 So, it was tagged in some unknown branch, not sure where... So I'm cherry picking: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=ef7308be2a3d6cb38a8c699766c59e951fd2b514 Into the 2.8.x branch, and tagging that 2.8.0 On Wed, Jun 19, 2013 at 1:40 PM, Shazron wrote: > Rhetorical question of course I am fixing this... > > > On Wed, Jun 19, 2013 at 1:36 PM, Shazron wrote: > >> I noticed in cordova-docs, the 2.8.0 tag was tagged in a commit on >> master, but not in the 2.8.x branch. Furthermore, the commit that was >> tagged is not even in the 2.8.x branch. Do I fix this? >> >> >> On Wed, Jun 19, 2013 at 11:51 AM, Shazron wrote: >> >>> Makes sense. I'll cherry-pick my changes to the relevant branches. >>> >>> >>> On Wed, Jun 19, 2013 at 11:45 AM, Michael Brooks < >>> mich...@michaelbrooks.ca> wrote: >>> Hey guys, There is no denying that the release branch practice is a little odd for cordova-docs. This is because the cordova-docs repository versions everything by directory (a legacy approach that we will someday shift away from). I'll hunt down the release wiki article and update it, but here is the rundown of the release details: Generating the documentation: --- The documentation is always generated from the master branch on the HEAD commit. The markdown is rendered to HTML as a one-to-one mapping of the /docs/ directory. Files can be merged together by defining the merge order in /docs/language/version/config.json Updating the documentation for an upcoming release: --- Always commit into master. When documenting an upcoming release, update the documentation under docs/en/edge/ Updating the documentation for a previous release: --- Always commit into master. Update the specific version (e.g. docs/en/2.7.0/) Also update each newer version until edge (e.g. docs/en/2.8.0/ and docs/en/edge) Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) Update each release branch tag to point to your new commit All in all, the release branches are a ceremony that are only used by coho. However, when cordova-docs is revamped to not include all versions, then the tags and release branches will make a lot more sense. Additionally, we'll be happy to have accurate tags for older versions. Michael On Tue, Jun 18, 2013 at 9:34 AM, Shazron wrote: > Yeah I'm interested in the flow as well. I think we published everything > again in older releases, not sure if we are still doing that going forward > > > On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard wrote: > > > On Jun 17, 2013, at 6:21 PM, Shazron wrote: > > > > > Should I bother? I know they will go in edge. There are a couple of > > issues: > > > https://issues.apache.org/jira/browse/CB-3753 > > > https://issues.apache.org/jira/browse/CB-3752 > > > > > > Basically it's weird since if I added it to the 2.8.0 folder, it's not > in > > > the 2.8.x branch, but is in master... > > > > > > So for older version updates, I don't bother with the older branches, > > yes? > > > Just master and the older folders > > > > @mwbrooks, when the docs get published to the web at the end of the > > release, does just edge or all version folders get published? > > > > If all folders get published, then correct, no need to commit to old > > branches, as all users that browse the docs online will see your change > in > > the 2.8.0 folder (which is somewhat confusingly [but cleverly] from > > master)… unless we ever build a patch release which doesn't seem to > happen, > > with the possible exception of 2.9.x. > >>> >>> >> >
Re: 2.9.0rc1 this coming monday??
I've pushed a "pl" branch to cordova-js that combines both loading techniques in the plugin_loader. I am in the process of testing on android/ios/bb10. Benn is working on testing that on the Windows Phone platforms. If it all works out I will merge this back into master on cordova-js, cherry pick into the 2.9.x branch and retag the JS. On 6/19/13 1:24 PM, "Jesse" wrote: >Yeah, to Braden's point while it may work, the behavior is not guaranteed, >and could break later. Also the contents of the file differ between the 2 >methods. > >Also discussing this in a quick chat with Fil, I think the best approach >is: >1. Plugman generates both files, a js and a json >2. cordova.js attempts XHR, and catches the exception, in which case it >continues on to a script injection attempt. > > >@purplecabbage >risingj.com > > >On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson >wrote: > >> JSON files are not valid Javascript code. >> >> >> On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj wrote: >> >> > Can we not have the script tag point to the json file? Does the >>extension >> > have to be .js? >> > >> > On 6/19/13 12:10 PM, "Jesse" wrote: >> > >> > >I was just going to suggest outputting both. That works for me. >> > > >> > >@purplecabbage >> > >risingj.com >> > > >> > > >> > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >> > >wrote: >> > > >> > >> Follow-up thought: No reason why we can't generate both >> > >>cordova_plugins.js >> > >> and cordova_plugins.json for a while. >> > >> >> > >> Braden >> > >> >> > >> >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < >> > bra...@chromium.org >> > >> >wrote: >> > >> >> > >> > Hm. This will of course require changing the name of the file >> Plugman >> > >> > generates, and it will mean users need to be very careful to be >> using >> > >> > sufficiently new plugman and cordova-js. >> > >> > >> > >> > In short: only the upgrade path for users bothers me about this; >>the >> > >> > change to use a .js file and
Re: Documentation update to previous version
Rhetorical question of course I am fixing this... On Wed, Jun 19, 2013 at 1:36 PM, Shazron wrote: > I noticed in cordova-docs, the 2.8.0 tag was tagged in a commit on master, > but not in the 2.8.x branch. Furthermore, the commit that was tagged is not > even in the 2.8.x branch. Do I fix this? > > > On Wed, Jun 19, 2013 at 11:51 AM, Shazron wrote: > >> Makes sense. I'll cherry-pick my changes to the relevant branches. >> >> >> On Wed, Jun 19, 2013 at 11:45 AM, Michael Brooks < >> mich...@michaelbrooks.ca> wrote: >> >>> Hey guys, >>> >>> There is no denying that the release branch practice is a little odd for >>> cordova-docs. This is because the cordova-docs repository versions >>> everything by directory (a legacy approach that we will someday shift >>> away >>> from). >>> >>> I'll hunt down the release wiki article and update it, but here is the >>> rundown of the release details: >>> >>> Generating the documentation: >>> --- >>> The documentation is always generated from the master branch on the HEAD >>> commit. >>> The markdown is rendered to HTML as a one-to-one mapping of the /docs/ >>> directory. >>> Files can be merged together by defining the merge order in >>> /docs/language/version/config.json >>> >>> Updating the documentation for an upcoming release: >>> --- >>> Always commit into master. >>> When documenting an upcoming release, update the documentation under >>> docs/en/edge/ >>> >>> Updating the documentation for a previous release: >>> --- >>> Always commit into master. >>> Update the specific version (e.g. docs/en/2.7.0/) >>> Also update each newer version until edge (e.g. docs/en/2.8.0/ and >>> docs/en/edge) >>> Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) >>> Update each release branch tag to point to your new commit >>> >>> All in all, the release branches are a ceremony that are only used by >>> coho. >>> However, when cordova-docs is revamped to not include all versions, then >>> the tags and release branches will make a lot more sense. Additionally, >>> we'll be happy to have accurate tags for older versions. >>> >>> Michael >>> >>> >>> On Tue, Jun 18, 2013 at 9:34 AM, Shazron wrote: >>> >>> > Yeah I'm interested in the flow as well. I think we published >>> everything >>> > again in older releases, not sure if we are still doing that going >>> forward >>> > >>> > >>> > On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard >>> wrote: >>> > >>> > > On Jun 17, 2013, at 6:21 PM, Shazron wrote: >>> > > >>> > > > Should I bother? I know they will go in edge. There are a couple of >>> > > issues: >>> > > > https://issues.apache.org/jira/browse/CB-3753 >>> > > > https://issues.apache.org/jira/browse/CB-3752 >>> > > > >>> > > > Basically it's weird since if I added it to the 2.8.0 folder, it's >>> not >>> > in >>> > > > the 2.8.x branch, but is in master... >>> > > > >>> > > > So for older version updates, I don't bother with the older >>> branches, >>> > > yes? >>> > > > Just master and the older folders >>> > > >>> > > @mwbrooks, when the docs get published to the web at the end of the >>> > > release, does just edge or all version folders get published? >>> > > >>> > > If all folders get published, then correct, no need to commit to old >>> > > branches, as all users that browse the docs online will see your >>> change >>> > in >>> > > the 2.8.0 folder (which is somewhat confusingly [but cleverly] from >>> > > master)… unless we ever build a patch release which doesn't seem to >>> > happen, >>> > > with the possible exception of 2.9.x. >>> > >>> >> >> >
Re: Documentation update to previous version
I noticed in cordova-docs, the 2.8.0 tag was tagged in a commit on master, but not in the 2.8.x branch. Furthermore, the commit that was tagged is not even in the 2.8.x branch. Do I fix this? On Wed, Jun 19, 2013 at 11:51 AM, Shazron wrote: > Makes sense. I'll cherry-pick my changes to the relevant branches. > > > On Wed, Jun 19, 2013 at 11:45 AM, Michael Brooks > wrote: > >> Hey guys, >> >> There is no denying that the release branch practice is a little odd for >> cordova-docs. This is because the cordova-docs repository versions >> everything by directory (a legacy approach that we will someday shift away >> from). >> >> I'll hunt down the release wiki article and update it, but here is the >> rundown of the release details: >> >> Generating the documentation: >> --- >> The documentation is always generated from the master branch on the HEAD >> commit. >> The markdown is rendered to HTML as a one-to-one mapping of the /docs/ >> directory. >> Files can be merged together by defining the merge order in >> /docs/language/version/config.json >> >> Updating the documentation for an upcoming release: >> --- >> Always commit into master. >> When documenting an upcoming release, update the documentation under >> docs/en/edge/ >> >> Updating the documentation for a previous release: >> --- >> Always commit into master. >> Update the specific version (e.g. docs/en/2.7.0/) >> Also update each newer version until edge (e.g. docs/en/2.8.0/ and >> docs/en/edge) >> Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) >> Update each release branch tag to point to your new commit >> >> All in all, the release branches are a ceremony that are only used by >> coho. >> However, when cordova-docs is revamped to not include all versions, then >> the tags and release branches will make a lot more sense. Additionally, >> we'll be happy to have accurate tags for older versions. >> >> Michael >> >> >> On Tue, Jun 18, 2013 at 9:34 AM, Shazron wrote: >> >> > Yeah I'm interested in the flow as well. I think we published everything >> > again in older releases, not sure if we are still doing that going >> forward >> > >> > >> > On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard >> wrote: >> > >> > > On Jun 17, 2013, at 6:21 PM, Shazron wrote: >> > > >> > > > Should I bother? I know they will go in edge. There are a couple of >> > > issues: >> > > > https://issues.apache.org/jira/browse/CB-3753 >> > > > https://issues.apache.org/jira/browse/CB-3752 >> > > > >> > > > Basically it's weird since if I added it to the 2.8.0 folder, it's >> not >> > in >> > > > the 2.8.x branch, but is in master... >> > > > >> > > > So for older version updates, I don't bother with the older >> branches, >> > > yes? >> > > > Just master and the older folders >> > > >> > > @mwbrooks, when the docs get published to the web at the end of the >> > > release, does just edge or all version folders get published? >> > > >> > > If all folders get published, then correct, no need to commit to old >> > > branches, as all users that browse the docs online will see your >> change >> > in >> > > the 2.8.0 folder (which is somewhat confusingly [but cleverly] from >> > > master)… unless we ever build a patch release which doesn't seem to >> > happen, >> > > with the possible exception of 2.9.x. >> > >> > >
Re: 2.9.0rc1 this coming monday??
Yeah, to Braden's point while it may work, the behavior is not guaranteed, and could break later. Also the contents of the file differ between the 2 methods. Also discussing this in a quick chat with Fil, I think the best approach is: 1. Plugman generates both files, a js and a json 2. cordova.js attempts XHR, and catches the exception, in which case it continues on to a script injection attempt. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 1:18 PM, Braden Shepherdson wrote: > JSON files are not valid Javascript code. > > > On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj wrote: > > > Can we not have the script tag point to the json file? Does the extension > > have to be .js? > > > > On 6/19/13 12:10 PM, "Jesse" wrote: > > > > >I was just going to suggest outputting both. That works for me. > > > > > >@purplecabbage > > >risingj.com > > > > > > > > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson > > >wrote: > > > > > >> Follow-up thought: No reason why we can't generate both > > >>cordova_plugins.js > > >> and cordova_plugins.json for a while. > > >> > > >> Braden > > >> > > >> > > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < > > bra...@chromium.org > > >> >wrote: > > >> > > >> > Hm. This will of course require changing the name of the file > Plugman > > >> > generates, and it will mean users need to be very careful to be > using > > >> > sufficiently new plugman and cordova-js. > > >> > > > >> > In short: only the upgrade path for users bothers me about this; the > > >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
Just pushed 0.7.12 of plugman that writes out both .js and .json files. The .js file is wrapped in a cordova.define module whereas the .json file is a simple array of plugins that were added using plugman. Next I will update cordova-js to: 1. Try to load the .json file using an xhr 2. If that throws, it will try to load the .js file by injecting a script tag. I will then test out this action on ios/android/bb10 and get Mapes to test it out on WP. THEN: retag will happen. Will report back shortly. On 6/19/13 1:18 PM, "Braden Shepherdson" wrote: >JSON files are not valid Javascript code. > > >On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj wrote: > >> Can we not have the script tag point to the json file? Does the >>extension >> have to be .js? >> >> On 6/19/13 12:10 PM, "Jesse" wrote: >> >> >I was just going to suggest outputting both. That works for me. >> > >> >@purplecabbage >> >risingj.com >> > >> > >> >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >> >wrote: >> > >> >> Follow-up thought: No reason why we can't generate both >> >>cordova_plugins.js >> >> and cordova_plugins.json for a while. >> >> >> >> Braden >> >> >> >> >> >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < >> bra...@chromium.org >> >> >wrote: >> >> >> >> > Hm. This will of course require changing the name of the file >>Plugman >> >> > generates, and it will mean users need to be very careful to be >>using >> >> > sufficiently new plugman and cordova-js. >> >> > >> >> > In short: only the upgrade path for users bothers me about this; >>the >> >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
JSON files are not valid Javascript code. On Wed, Jun 19, 2013 at 4:10 PM, Filip Maj wrote: > Can we not have the script tag point to the json file? Does the extension > have to be .js? > > On 6/19/13 12:10 PM, "Jesse" wrote: > > >I was just going to suggest outputting both. That works for me. > > > >@purplecabbage > >risingj.com > > > > > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson > >wrote: > > > >> Follow-up thought: No reason why we can't generate both > >>cordova_plugins.js > >> and cordova_plugins.json for a while. > >> > >> Braden > >> > >> > >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson < > bra...@chromium.org > >> >wrote: > >> > >> > Hm. This will of course require changing the name of the file Plugman > >> > generates, and it will mean users need to be very careful to be using > >> > sufficiently new plugman and cordova-js. > >> > > >> > In short: only the upgrade path for users bothers me about this; the > >> > change to use a .js file and
Re: BB10 bundling of node.js
Still a -1, cordova (and all it's projects) should use the globally installed version of node. If someone needs multiple versions of node the should probably use nvm [1] to manage it. IMHO this is a user problem and not something we should magically solve via bundled copies of node or hardcoded paths to specific versions of node. I agree we should have a version of node we support, it just needs to be consistent and common across all of our tools and require the user to have that version range in their path. [1] - https://github.com/creationix/nvm On Wed, Jun 19, 2013 at 3:57 PM, Bryan Higgins wrote: > For 3.0 will there still be a ZIP file released by Apache? Will the > instructions be download the latest version of node then run "npm install > -g "? > > My assumption was the individual project templates will continue to work > independently of CLI. > > Also, keep in mind that CLI invokes BB via shell scripts which in turn call > node. So for environments where people need different versions of node > installed, invoking CLI with an alternate node version will cause BB to be > invoked via the globally installed version. Perhaps that is an edge case, > but it's still something that needs to be supported by allowing them to > configure node path for BB. > > > On Wed, Jun 19, 2013 at 3:30 PM, Gord Tanner wrote: > > > I would expect they would have a supported node version when they type: > > > > "npm install cordova" > > > > which would do any version checks in the package.json [1] for supported > > node versions > > > > [1] - > > > > > https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=package.json;hb=HEAD > > > > > > On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins > >wrote: > > > > > So for Cordova 3.0 in general, users will be required to pre-install a > > > minimum version of node globally? > > > > > > We have had issues where upgrading node breaks stuff. I'd like to avoid > > > that and give users flexibility with their own system configuration. > > > > > > > > > On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner > wrote: > > > > > > > -1 > > > > > > > > I would rather we just use the system version of node which would be > > the > > > > same version as the CLI. I can't think of any reason a specific > > platform > > > > (aka BlackBerry) would need a special version of a common dependency. > > > > > > > > Also I don't think you can bundle binaries in an apache release. > > > > > > > > > > > > On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins < > > bhigg...@blackberry.com > > > > >wrote: > > > > > > > > > I'd like to reopen the topic of bundling node js into the > blackberry > > > > > platform. > > > > > > > > > > I have personally gotten feedback from users of errors which were > > > caused > > > > by > > > > > node version inconsistencies. We have since updated the check_req > > > script > > > > to > > > > > test for the minimum version of node we require, but that is not an > > > ideal > > > > > solution since users may need a different node version installed > > > globally > > > > > for other software. > > > > > > > > > > At a minimum, I'd like to give users the option to point to an > > > alternate > > > > > version of node. I have logged a JIRA issue for that. [1] > > > > > > > > > > What I'd prefer to do, is bundle the node binaries into the > > > distribution. > > > > > That would completely eliminate the dependency. Users would only > need > > > to > > > > > worry about setting up the native SDK. > > > > > > > > > > We already do this in the WebWorks SDK [2] > > > > > > > > > > I'm interested how the community feels about this. Are there any > > > > licensing > > > > > concerns in Apache hosting binaries without source? > > > > > > > > > > [1] https://issues.apache.org/jira/browse/CB-3798 > > > > > [2] > > > > > > > > > > > > > > > > > > > > https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node > > > > > > > > > > > > > > >
Re: 2.9.0rc1 this coming monday??
Can we not have the script tag point to the json file? Does the extension have to be .js? On 6/19/13 12:10 PM, "Jesse" wrote: >I was just going to suggest outputting both. That works for me. > >@purplecabbage >risingj.com > > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >wrote: > >> Follow-up thought: No reason why we can't generate both >>cordova_plugins.js >> and cordova_plugins.json for a while. >> >> Braden >> >> >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson > >wrote: >> >> > Hm. This will of course require changing the name of the file Plugman >> > generates, and it will mean users need to be very careful to be using >> > sufficiently new plugman and cordova-js. >> > >> > In short: only the upgrade path for users bothers me about this; the >> > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
I'll make this change in plugman now. On 6/19/13 12:10 PM, "Jesse" wrote: >I was just going to suggest outputting both. That works for me. > >@purplecabbage >risingj.com > > >On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson >wrote: > >> Follow-up thought: No reason why we can't generate both >>cordova_plugins.js >> and cordova_plugins.json for a while. >> >> Braden >> >> >> On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson > >wrote: >> >> > Hm. This will of course require changing the name of the file Plugman >> > generates, and it will mean users need to be very careful to be using >> > sufficiently new plugman and cordova-js. >> > >> > In short: only the upgrade path for users bothers me about this; the >> > change to use a .js file and
Fwd: Media API, DataResource, and empty URLs
The automated tests for Media frequently call new Media() with no URL, which sends a null to the "create" action. In the past, this got turned into the string "null" in Java, which was handled as a file named "null" that didn't exist, and nothing crashed. DataResource is fine with the files not existing, but it's not fine with "null" as a filename since it neither has a URL scheme nor is it an absolute path. Is there a reason why new Media() should work rather than throwing IllegalArgumentExceptions for trying to read files with relative paths? Should I detect and gracefully handle null being given as the media URL in Javascript? In Java? Should I instead change the mobile-spec tests to use "file:///dummy" or similar? Braden
Re: BB10 bundling of node.js
For 3.0 will there still be a ZIP file released by Apache? Will the instructions be download the latest version of node then run "npm install -g "? My assumption was the individual project templates will continue to work independently of CLI. Also, keep in mind that CLI invokes BB via shell scripts which in turn call node. So for environments where people need different versions of node installed, invoking CLI with an alternate node version will cause BB to be invoked via the globally installed version. Perhaps that is an edge case, but it's still something that needs to be supported by allowing them to configure node path for BB. On Wed, Jun 19, 2013 at 3:30 PM, Gord Tanner wrote: > I would expect they would have a supported node version when they type: > > "npm install cordova" > > which would do any version checks in the package.json [1] for supported > node versions > > [1] - > > https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=package.json;hb=HEAD > > > On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins >wrote: > > > So for Cordova 3.0 in general, users will be required to pre-install a > > minimum version of node globally? > > > > We have had issues where upgrading node breaks stuff. I'd like to avoid > > that and give users flexibility with their own system configuration. > > > > > > On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner wrote: > > > > > -1 > > > > > > I would rather we just use the system version of node which would be > the > > > same version as the CLI. I can't think of any reason a specific > platform > > > (aka BlackBerry) would need a special version of a common dependency. > > > > > > Also I don't think you can bundle binaries in an apache release. > > > > > > > > > On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins < > bhigg...@blackberry.com > > > >wrote: > > > > > > > I'd like to reopen the topic of bundling node js into the blackberry > > > > platform. > > > > > > > > I have personally gotten feedback from users of errors which were > > caused > > > by > > > > node version inconsistencies. We have since updated the check_req > > script > > > to > > > > test for the minimum version of node we require, but that is not an > > ideal > > > > solution since users may need a different node version installed > > globally > > > > for other software. > > > > > > > > At a minimum, I'd like to give users the option to point to an > > alternate > > > > version of node. I have logged a JIRA issue for that. [1] > > > > > > > > What I'd prefer to do, is bundle the node binaries into the > > distribution. > > > > That would completely eliminate the dependency. Users would only need > > to > > > > worry about setting up the native SDK. > > > > > > > > We already do this in the WebWorks SDK [2] > > > > > > > > I'm interested how the community feels about this. Are there any > > > licensing > > > > concerns in Apache hosting binaries without source? > > > > > > > > [1] https://issues.apache.org/jira/browse/CB-3798 > > > > [2] > > > > > > > > > > > > > > https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node > > > > > > > > > >
Re: BB10 bundling of node.js
I would expect they would have a supported node version when they type: "npm install cordova" which would do any version checks in the package.json [1] for supported node versions [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blob_plain;f=package.json;hb=HEAD On Wed, Jun 19, 2013 at 3:22 PM, Bryan Higgins wrote: > So for Cordova 3.0 in general, users will be required to pre-install a > minimum version of node globally? > > We have had issues where upgrading node breaks stuff. I'd like to avoid > that and give users flexibility with their own system configuration. > > > On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner wrote: > > > -1 > > > > I would rather we just use the system version of node which would be the > > same version as the CLI. I can't think of any reason a specific platform > > (aka BlackBerry) would need a special version of a common dependency. > > > > Also I don't think you can bundle binaries in an apache release. > > > > > > On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins > >wrote: > > > > > I'd like to reopen the topic of bundling node js into the blackberry > > > platform. > > > > > > I have personally gotten feedback from users of errors which were > caused > > by > > > node version inconsistencies. We have since updated the check_req > script > > to > > > test for the minimum version of node we require, but that is not an > ideal > > > solution since users may need a different node version installed > globally > > > for other software. > > > > > > At a minimum, I'd like to give users the option to point to an > alternate > > > version of node. I have logged a JIRA issue for that. [1] > > > > > > What I'd prefer to do, is bundle the node binaries into the > distribution. > > > That would completely eliminate the dependency. Users would only need > to > > > worry about setting up the native SDK. > > > > > > We already do this in the WebWorks SDK [2] > > > > > > I'm interested how the community feels about this. Are there any > > licensing > > > concerns in Apache hosting binaries without source? > > > > > > [1] https://issues.apache.org/jira/browse/CB-3798 > > > [2] > > > > > > > > > https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node > > > > > >
Re: BB10 bundling of node.js
So for Cordova 3.0 in general, users will be required to pre-install a minimum version of node globally? We have had issues where upgrading node breaks stuff. I'd like to avoid that and give users flexibility with their own system configuration. On Wed, Jun 19, 2013 at 3:09 PM, Gord Tanner wrote: > -1 > > I would rather we just use the system version of node which would be the > same version as the CLI. I can't think of any reason a specific platform > (aka BlackBerry) would need a special version of a common dependency. > > Also I don't think you can bundle binaries in an apache release. > > > On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins >wrote: > > > I'd like to reopen the topic of bundling node js into the blackberry > > platform. > > > > I have personally gotten feedback from users of errors which were caused > by > > node version inconsistencies. We have since updated the check_req script > to > > test for the minimum version of node we require, but that is not an ideal > > solution since users may need a different node version installed globally > > for other software. > > > > At a minimum, I'd like to give users the option to point to an alternate > > version of node. I have logged a JIRA issue for that. [1] > > > > What I'd prefer to do, is bundle the node binaries into the distribution. > > That would completely eliminate the dependency. Users would only need to > > worry about setting up the native SDK. > > > > We already do this in the WebWorks SDK [2] > > > > I'm interested how the community feels about this. Are there any > licensing > > concerns in Apache hosting binaries without source? > > > > [1] https://issues.apache.org/jira/browse/CB-3798 > > [2] > > > > > https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node > > >
Re: 2.9.0rc1 this coming monday??
I was just going to suggest outputting both. That works for me. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:06 PM, Braden Shepherdson wrote: > Follow-up thought: No reason why we can't generate both cordova_plugins.js > and cordova_plugins.json for a while. > > Braden > > > On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson >wrote: > > > Hm. This will of course require changing the name of the file Plugman > > generates, and it will mean users need to be very careful to be using > > sufficiently new plugman and cordova-js. > > > > In short: only the upgrade path for users bothers me about this; the > > change to use a .js file and
Re: BB10 bundling of node.js
-1 I would rather we just use the system version of node which would be the same version as the CLI. I can't think of any reason a specific platform (aka BlackBerry) would need a special version of a common dependency. Also I don't think you can bundle binaries in an apache release. On Wed, Jun 19, 2013 at 3:01 PM, Bryan Higgins wrote: > I'd like to reopen the topic of bundling node js into the blackberry > platform. > > I have personally gotten feedback from users of errors which were caused by > node version inconsistencies. We have since updated the check_req script to > test for the minimum version of node we require, but that is not an ideal > solution since users may need a different node version installed globally > for other software. > > At a minimum, I'd like to give users the option to point to an alternate > version of node. I have logged a JIRA issue for that. [1] > > What I'd prefer to do, is bundle the node binaries into the distribution. > That would completely eliminate the dependency. Users would only need to > worry about setting up the native SDK. > > We already do this in the WebWorks SDK [2] > > I'm interested how the community feels about this. Are there any licensing > concerns in Apache hosting binaries without source? > > [1] https://issues.apache.org/jira/browse/CB-3798 > [2] > > https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node >
Re: 2.9.0rc1 this coming monday??
Follow-up thought: No reason why we can't generate both cordova_plugins.js and cordova_plugins.json for a while. Braden On Wed, Jun 19, 2013 at 3:06 PM, Braden Shepherdson wrote: > Hm. This will of course require changing the name of the file Plugman > generates, and it will mean users need to be very careful to be using > sufficiently new plugman and cordova-js. > > In short: only the upgrade path for users bothers me about this; the > change to use a .js file and
Re: 2.9.0rc1 this coming monday??
Hm. This will of course require changing the name of the file Plugman generates, and it will mean users need to be very careful to be using sufficiently new plugman and cordova-js. In short: only the upgrade path for users bothers me about this; the change to use a .js file and
Re: 2.9.0rc1 this coming monday??
+1 Sorry, I thought this was merged already. There are implications to PlugMan as well, since PlugMan is responsible for writing the file. @purplecabbage risingj.com On Wed, Jun 19, 2013 at 12:00 PM, Filip Maj wrote: > Ahh shit I think we need to retag the JS > > The dynamic loading of cordova_plugins.json doesn't work on Windows Phone > *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse > converged on has been sitting on a branch. You can compare it to apache's > master branch at [1]. Essentially it creates a script tag pointing to the > cordova_plugins.json file instead of XHR'ing to it. The XHR approach > throws an "Access Denied" error on WP*. > > With this being the last release before 3.0, I think we need to include > this bit of functionality. > > Thoughts? > > [1] https://github.com/purplecabbage/cordova-js/compare/PL > > On 6/18/13 7:30 AM, "Shazron" wrote: > > >I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I > >wanted to get into rc1, but I don't want to rush it, I'll get to all the > >rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get > >that done. > > > > > >On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj wrote: > > > >> I have the rc tag issues for mobile-spec and the JS assigned to me. I > >>will > >> tag them tomorrow morning unless I hear otherwise. > >> > >> On 6/17/13 2:01 PM, "James Jong" wrote: > >> > >> >I'm back this week and will start looking at a couple of the ones Shaz > >> >mentioned: CB-3757 , CB-3562. > >> >-James Jong > >> > > >> >On Jun 17, 2013, at 3:21 PM, Andrew Grieve > >>wrote: > >> > > >> >> I would have liked to fix a few more bugs, namely: > >> >> - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) > >> >> - iOS loading bugs (CB-3005, CB-3530, CB-3534) > >> >> - DisallowOverscroll setting inconsistency between Android and iOS > >> >>(Jesse > >> >> brought this up - no bug filed for this yet I think) > >> >> > >> >> I was also planning on working on adding some Plugin-behaving-nicely > >> >>checks > >> >> on the native side. E.g. log a message if a plugin takes spends more > >> >>than > >> >> 50ms on the UI (for iOS) or WebCore (for Android) thread. > >> >> > >> >> Of course, I haven't done anything for over 2 weeks, and so I clearly > >> >>won't > >> >> get this all done in the next few hours :P. > >> >> > >> >> So, I'm fine with starting the release now so that we can focus more > >>on > >> >> 3.0. It'll give us a chance to practice our release-foo some more, > >>and > >> >> hopefully make more enhancements to the coho tool (Steven - I'm > >>looking > >> >>at > >> >> you for the uploading a release part :P). > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj wrote: > >> >> > >> >>> Thanks Jeff! > >> >>> > >> >>> On 6/17/13 10:28 AM, "Jeffrey Heifetz" > >> wrote: > >> >>> > >> Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, > >> CB-3799 > >> > >> On 13-06-17 1:26 PM, "Filip Maj" wrote: > >> > >> > Good stuff Bryan, is this being tracked on issues anywhere? I'd > >>like > >> >to > >> > refer other issues (CLI) to this feature you're speaking of. > >> > > >> > On 6/17/13 10:18 AM, "Bryan Higgins" > >>wrote: > >> > > >> >> For BB10, we're working on moving out the environment settings > >>from > >> >> project > >> >> to HOME. > >> >> > >> >> That work is pretty much done. We should have it tested and > >> >>committed > >> >> within the next few hours. > >> >> > >> >> > >> >> On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland > >> >> > > >> >> wrote: > >> >> > >> >>> The only thing that I'm working on this morning that could be a > >> >>> candidate > >> >>> for 2.9 is an extension to FileWriter.write(Blob) that will > >>accept > >> >>>a > >> >>> Cordova File object in place of a native Blob object. > >> >>> > >> >>> (FileWriter.write(Blob) is CB-2406, and new for 2.9) > >> >>> > >> >>> If we consider this a bug to be fixed, then I can take care of > >>it > >> >>> post-rc1. > >> >>> Otherwise, I'll work quickly to get it in this morning. > >> >>> > >> >>> > >> >>> > >> >>> On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj > >>wrote: > >> >>> > >> SO: we're doing this today ya? Any objections? Anyone still > >> working > >> >>> on > >> something that they are gunning to get in for 2.9? > >> > >> On 6/14/13 1:12 PM, "Michael Brooks" > > >> >>> wrote: > >> > >> > Monday RC1 sounds good to me. > >> > > >> > > >> > On Thu, Jun 13, 2013 at 11:19 AM, Shazron > >> >>> wrote: > >> > > >> >> Looking at iOS 2.9.0: > >> >> > >> >> Definitely as you said: > >> >>> https://issues.apache.org/jira/browse/CB-3757 > >> >> Then all iOS cli and docs i
BB10 bundling of node.js
I'd like to reopen the topic of bundling node js into the blackberry platform. I have personally gotten feedback from users of errors which were caused by node version inconsistencies. We have since updated the check_req script to test for the minimum version of node we require, but that is not an ideal solution since users may need a different node version installed globally for other software. At a minimum, I'd like to give users the option to point to an alternate version of node. I have logged a JIRA issue for that. [1] What I'd prefer to do, is bundle the node binaries into the distribution. That would completely eliminate the dependency. Users would only need to worry about setting up the native SDK. We already do this in the WebWorks SDK [2] I'm interested how the community feels about this. Are there any licensing concerns in Apache hosting binaries without source? [1] https://issues.apache.org/jira/browse/CB-3798 [2] https://github.com/blackberry/BB10-Webworks-Packager/tree/master/third_party/node
Re: 2.9.0rc1 this coming monday??
Ahh shit I think we need to retag the JS The dynamic loading of cordova_plugins.json doesn't work on Windows Phone *, as we discussed in the 2.8.0rc1 tag thread. The workaround that Jesse converged on has been sitting on a branch. You can compare it to apache's master branch at [1]. Essentially it creates a script tag pointing to the cordova_plugins.json file instead of XHR'ing to it. The XHR approach throws an "Access Denied" error on WP*. With this being the last release before 3.0, I think we need to include this bit of functionality. Thoughts? [1] https://github.com/purplecabbage/cordova-js/compare/PL On 6/18/13 7:30 AM, "Shazron" wrote: >I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I >wanted to get into rc1, but I don't want to rush it, I'll get to all the >rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get >that done. > > >On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj wrote: > >> I have the rc tag issues for mobile-spec and the JS assigned to me. I >>will >> tag them tomorrow morning unless I hear otherwise. >> >> On 6/17/13 2:01 PM, "James Jong" wrote: >> >> >I'm back this week and will start looking at a couple of the ones Shaz >> >mentioned: CB-3757 , CB-3562. >> >-James Jong >> > >> >On Jun 17, 2013, at 3:21 PM, Andrew Grieve >>wrote: >> > >> >> I would have liked to fix a few more bugs, namely: >> >> - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) >> >> - iOS loading bugs (CB-3005, CB-3530, CB-3534) >> >> - DisallowOverscroll setting inconsistency between Android and iOS >> >>(Jesse >> >> brought this up - no bug filed for this yet I think) >> >> >> >> I was also planning on working on adding some Plugin-behaving-nicely >> >>checks >> >> on the native side. E.g. log a message if a plugin takes spends more >> >>than >> >> 50ms on the UI (for iOS) or WebCore (for Android) thread. >> >> >> >> Of course, I haven't done anything for over 2 weeks, and so I clearly >> >>won't >> >> get this all done in the next few hours :P. >> >> >> >> So, I'm fine with starting the release now so that we can focus more >>on >> >> 3.0. It'll give us a chance to practice our release-foo some more, >>and >> >> hopefully make more enhancements to the coho tool (Steven - I'm >>looking >> >>at >> >> you for the uploading a release part :P). >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj wrote: >> >> >> >>> Thanks Jeff! >> >>> >> >>> On 6/17/13 10:28 AM, "Jeffrey Heifetz" >> wrote: >> >>> >> Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, >> CB-3799 >> >> On 13-06-17 1:26 PM, "Filip Maj" wrote: >> >> > Good stuff Bryan, is this being tracked on issues anywhere? I'd >>like >> >to >> > refer other issues (CLI) to this feature you're speaking of. >> > >> > On 6/17/13 10:18 AM, "Bryan Higgins" >>wrote: >> > >> >> For BB10, we're working on moving out the environment settings >>from >> >> project >> >> to HOME. >> >> >> >> That work is pretty much done. We should have it tested and >> >>committed >> >> within the next few hours. >> >> >> >> >> >> On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland >>> > >> >> wrote: >> >> >> >>> The only thing that I'm working on this morning that could be a >> >>> candidate >> >>> for 2.9 is an extension to FileWriter.write(Blob) that will >>accept >> >>>a >> >>> Cordova File object in place of a native Blob object. >> >>> >> >>> (FileWriter.write(Blob) is CB-2406, and new for 2.9) >> >>> >> >>> If we consider this a bug to be fixed, then I can take care of >>it >> >>> post-rc1. >> >>> Otherwise, I'll work quickly to get it in this morning. >> >>> >> >>> >> >>> >> >>> On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj >>wrote: >> >>> >> SO: we're doing this today ya? Any objections? Anyone still >> working >> >>> on >> something that they are gunning to get in for 2.9? >> >> On 6/14/13 1:12 PM, "Michael Brooks" >> >>> wrote: >> >> > Monday RC1 sounds good to me. >> > >> > >> > On Thu, Jun 13, 2013 at 11:19 AM, Shazron >> >>> wrote: >> > >> >> Looking at iOS 2.9.0: >> >> >> >> Definitely as you said: >> >>> https://issues.apache.org/jira/browse/CB-3757 >> >> Then all iOS cli and docs issues. >> >> >> >> If there is time for iOS I am going to tackle: >> >> https://issues.apache.org/jira/browse/CB-3303 (to fix) >> >> https://issues.apache.org/jira/browse/CB-3451 (to >>investigate, >> >>> no >> >>> fix >> >> yet) >> >> https://issues.apache.org/jira/browse/CB-3567 (there is a PR >>to >> >> investigate) >> >> https://issues.apache.org/jira/browse/CB-3562 (fix in the >> issue, >> >>> to >> >> evaluate) >> >
Re: Documentation update to previous version
Makes sense. I'll cherry-pick my changes to the relevant branches. On Wed, Jun 19, 2013 at 11:45 AM, Michael Brooks wrote: > Hey guys, > > There is no denying that the release branch practice is a little odd for > cordova-docs. This is because the cordova-docs repository versions > everything by directory (a legacy approach that we will someday shift away > from). > > I'll hunt down the release wiki article and update it, but here is the > rundown of the release details: > > Generating the documentation: > --- > The documentation is always generated from the master branch on the HEAD > commit. > The markdown is rendered to HTML as a one-to-one mapping of the /docs/ > directory. > Files can be merged together by defining the merge order in > /docs/language/version/config.json > > Updating the documentation for an upcoming release: > --- > Always commit into master. > When documenting an upcoming release, update the documentation under > docs/en/edge/ > > Updating the documentation for a previous release: > --- > Always commit into master. > Update the specific version (e.g. docs/en/2.7.0/) > Also update each newer version until edge (e.g. docs/en/2.8.0/ and > docs/en/edge) > Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) > Update each release branch tag to point to your new commit > > All in all, the release branches are a ceremony that are only used by coho. > However, when cordova-docs is revamped to not include all versions, then > the tags and release branches will make a lot more sense. Additionally, > we'll be happy to have accurate tags for older versions. > > Michael > > > On Tue, Jun 18, 2013 at 9:34 AM, Shazron wrote: > > > Yeah I'm interested in the flow as well. I think we published everything > > again in older releases, not sure if we are still doing that going > forward > > > > > > On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard > wrote: > > > > > On Jun 17, 2013, at 6:21 PM, Shazron wrote: > > > > > > > Should I bother? I know they will go in edge. There are a couple of > > > issues: > > > > https://issues.apache.org/jira/browse/CB-3753 > > > > https://issues.apache.org/jira/browse/CB-3752 > > > > > > > > Basically it's weird since if I added it to the 2.8.0 folder, it's > not > > in > > > > the 2.8.x branch, but is in master... > > > > > > > > So for older version updates, I don't bother with the older branches, > > > yes? > > > > Just master and the older folders > > > > > > @mwbrooks, when the docs get published to the web at the end of the > > > release, does just edge or all version folders get published? > > > > > > If all folders get published, then correct, no need to commit to old > > > branches, as all users that browse the docs online will see your change > > in > > > the 2.8.0 folder (which is somewhat confusingly [but cleverly] from > > > master)… unless we ever build a patch release which doesn't seem to > > happen, > > > with the possible exception of 2.9.x. > > >
Re: Documentation update to previous version
Hey guys, There is no denying that the release branch practice is a little odd for cordova-docs. This is because the cordova-docs repository versions everything by directory (a legacy approach that we will someday shift away from). I'll hunt down the release wiki article and update it, but here is the rundown of the release details: Generating the documentation: --- The documentation is always generated from the master branch on the HEAD commit. The markdown is rendered to HTML as a one-to-one mapping of the /docs/ directory. Files can be merged together by defining the merge order in /docs/language/version/config.json Updating the documentation for an upcoming release: --- Always commit into master. When documenting an upcoming release, update the documentation under docs/en/edge/ Updating the documentation for a previous release: --- Always commit into master. Update the specific version (e.g. docs/en/2.7.0/) Also update each newer version until edge (e.g. docs/en/2.8.0/ and docs/en/edge) Cherry-pick to the relevant release branch(es) (e.g. 2.7.x and 2.8.x) Update each release branch tag to point to your new commit All in all, the release branches are a ceremony that are only used by coho. However, when cordova-docs is revamped to not include all versions, then the tags and release branches will make a lot more sense. Additionally, we'll be happy to have accurate tags for older versions. Michael On Tue, Jun 18, 2013 at 9:34 AM, Shazron wrote: > Yeah I'm interested in the flow as well. I think we published everything > again in older releases, not sure if we are still doing that going forward > > > On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard wrote: > > > On Jun 17, 2013, at 6:21 PM, Shazron wrote: > > > > > Should I bother? I know they will go in edge. There are a couple of > > issues: > > > https://issues.apache.org/jira/browse/CB-3753 > > > https://issues.apache.org/jira/browse/CB-3752 > > > > > > Basically it's weird since if I added it to the 2.8.0 folder, it's not > in > > > the 2.8.x branch, but is in master... > > > > > > So for older version updates, I don't bother with the older branches, > > yes? > > > Just master and the older folders > > > > @mwbrooks, when the docs get published to the web at the end of the > > release, does just edge or all version folders get published? > > > > If all folders get published, then correct, no need to commit to old > > branches, as all users that browse the docs online will see your change > in > > the 2.8.0 folder (which is somewhat confusingly [but cleverly] from > > master)… unless we ever build a patch release which doesn't seem to > happen, > > with the possible exception of 2.9.x. >
Re: Cordova.js now at 2.9.0rc1 for real
One further piece of information for this Node version nonsense: 0.6 is too old. 0.8 is too old, but only very thinly: we call os.tmpdir(), which exists only in 0.10, renamed from os.tmpDir() in 0.8. os.tmpDir() still exists as a synonym in 0.10 (though I don't think it appears in the documentation, it's clearly there in the source), so we can change the spelling of these few calls and return our support for Node 0.8 in the CLI tools. I think this is probably a good idea. Braden On Wed, Jun 19, 2013 at 2:17 PM, Steven Gill wrote: > I use nvm to switch back to node v0.8.14 when running jake on cordova-js. > Not a good solution. > > > On Wed, Jun 19, 2013 at 11:08 AM, Andrew Grieve >wrote: > > > hmm, I did indeed just upgrade my node version. blowing away node_modules > > didn't seem to fix it though. > > > > > > On Wed, Jun 19, 2013 at 12:04 PM, Braden Shepherdson < > bra...@chromium.org > > >wrote: > > > > > This happened to me back when I upgraded node. I ended up doing rm -rf > > > node_modules and then npm install. I eventually managed to claw my way > > back > > > to a working Jake. Why it fails utterly silently, and with code 0, > > puzzles > > > me. > > > > > > Braden > > > > > > > > > On Wed, Jun 19, 2013 at 12:00 PM, Jeffrey Heifetz > > > wrote: > > > > > > > I've been seeing similar issues with Jake since I've upgraded my node > > and > > > > it is definitely related to Jake failing with dependencies. I have > yet > > to > > > > find the real root cause. > > > > > > > > On 13-06-18 8:27 PM, "Andrew Grieve" wrote: > > > > > > > > >As both Jesse and Shaz pointed out, I ran coho to update cordova.js > > > > >snapshots, but it resulted in them being set to 2.7.0 instead of > > 2.9.0. > > > > > > > > > >This is now fixed (new commits for 2.9.0rc1), and I've updated the > > coho > > > > >script to not push by default (so that commits can be inspected). > > > > > > > > > >The root problem is that jake is existing without failure and > without > > > > >printing anything to the console. Can anyone else verify if this is > > > > >happening for them? > > > > > > > > > >I debugged it as far as to see that removing the > "complainwhitespace" > > > > >dependency from the "hint" task fixed things, but I don't know why > > that > > > > >is. > > > > > > > > > > > > - > > > > This transmission (including any attachments) may contain > confidential > > > > information, privileged material (including material protected by the > > > > solicitor-client or other applicable privileges), or constitute > > > non-public > > > > information. Any use of this information by anyone other than the > > > intended > > > > recipient is prohibited. If you have received this transmission in > > error, > > > > please immediately reply to the sender and delete this information > from > > > > your system. Use, dissemination, distribution, or reproduction of > this > > > > transmission by unintended recipients is not authorized and may be > > > unlawful. > > > > > > > > > >
Re: Cordova.js now at 2.9.0rc1 for real
I use nvm to switch back to node v0.8.14 when running jake on cordova-js. Not a good solution. On Wed, Jun 19, 2013 at 11:08 AM, Andrew Grieve wrote: > hmm, I did indeed just upgrade my node version. blowing away node_modules > didn't seem to fix it though. > > > On Wed, Jun 19, 2013 at 12:04 PM, Braden Shepherdson >wrote: > > > This happened to me back when I upgraded node. I ended up doing rm -rf > > node_modules and then npm install. I eventually managed to claw my way > back > > to a working Jake. Why it fails utterly silently, and with code 0, > puzzles > > me. > > > > Braden > > > > > > On Wed, Jun 19, 2013 at 12:00 PM, Jeffrey Heifetz > > wrote: > > > > > I've been seeing similar issues with Jake since I've upgraded my node > and > > > it is definitely related to Jake failing with dependencies. I have yet > to > > > find the real root cause. > > > > > > On 13-06-18 8:27 PM, "Andrew Grieve" wrote: > > > > > > >As both Jesse and Shaz pointed out, I ran coho to update cordova.js > > > >snapshots, but it resulted in them being set to 2.7.0 instead of > 2.9.0. > > > > > > > >This is now fixed (new commits for 2.9.0rc1), and I've updated the > coho > > > >script to not push by default (so that commits can be inspected). > > > > > > > >The root problem is that jake is existing without failure and without > > > >printing anything to the console. Can anyone else verify if this is > > > >happening for them? > > > > > > > >I debugged it as far as to see that removing the "complainwhitespace" > > > >dependency from the "hint" task fixed things, but I don't know why > that > > > >is. > > > > > > > > > - > > > This transmission (including any attachments) may contain confidential > > > information, privileged material (including material protected by the > > > solicitor-client or other applicable privileges), or constitute > > non-public > > > information. Any use of this information by anyone other than the > > intended > > > recipient is prohibited. If you have received this transmission in > error, > > > please immediately reply to the sender and delete this information from > > > your system. Use, dissemination, distribution, or reproduction of this > > > transmission by unintended recipients is not authorized and may be > > unlawful. > > > > > >
Re: Cordova.js now at 2.9.0rc1 for real
hmm, I did indeed just upgrade my node version. blowing away node_modules didn't seem to fix it though. On Wed, Jun 19, 2013 at 12:04 PM, Braden Shepherdson wrote: > This happened to me back when I upgraded node. I ended up doing rm -rf > node_modules and then npm install. I eventually managed to claw my way back > to a working Jake. Why it fails utterly silently, and with code 0, puzzles > me. > > Braden > > > On Wed, Jun 19, 2013 at 12:00 PM, Jeffrey Heifetz > wrote: > > > I've been seeing similar issues with Jake since I've upgraded my node and > > it is definitely related to Jake failing with dependencies. I have yet to > > find the real root cause. > > > > On 13-06-18 8:27 PM, "Andrew Grieve" wrote: > > > > >As both Jesse and Shaz pointed out, I ran coho to update cordova.js > > >snapshots, but it resulted in them being set to 2.7.0 instead of 2.9.0. > > > > > >This is now fixed (new commits for 2.9.0rc1), and I've updated the coho > > >script to not push by default (so that commits can be inspected). > > > > > >The root problem is that jake is existing without failure and without > > >printing anything to the console. Can anyone else verify if this is > > >happening for them? > > > > > >I debugged it as far as to see that removing the "complainwhitespace" > > >dependency from the "hint" task fixed things, but I don't know why that > > >is. > > > > > > - > > This transmission (including any attachments) may contain confidential > > information, privileged material (including material protected by the > > solicitor-client or other applicable privileges), or constitute > non-public > > information. Any use of this information by anyone other than the > intended > > recipient is prohibited. If you have received this transmission in error, > > please immediately reply to the sender and delete this information from > > your system. Use, dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and may be > unlawful. > > >
Re: Apache VM for Medic's CouchDB
that would be fantastic! On Wed, Jun 19, 2013 at 9:59 AM, Filip Maj wrote: > Would love to see this, thanks for taking the initiative on this Mike! > > On 6/19/13 7:19 AM, "Andrew Grieve" wrote: > > >Sounds great! > > > > > >On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau > >wrote: > > > >> Hello everyone, > >> > >> I have been working the last week on getting medic up and running here > >>at > >> our office, and so far things are going pretty well. I would like to > >>start > >> contributing our tests back to the community pretty soon. However, I > >> contacted Fil about flowing our test results back to the CI database, > >>and > >> he informed me that unfortunately the EC2 instance has been removed. > >> > >> I would like to propose that we have the Apache folks set us up with a > >> standard Linux VM that we can use to host the CouchDB server to collect > >> test results. Using an Apache VM seems to be more in the Apache spirit > >>as > >> opposed to an EC2 instance. Since it would be more centralized and > >> community owned, it would potentially make it easier for other groups to > >> contribute test results. The VM can also serve as a home for any future > >> dumps or hosted scripts that we need. > >> > >> Any thoughts on this? If there are no problems, then can somebody > >>involved > >> with ASF help me create the relevant INFRA issues? > >> > >> Thanks, > >> Mike Billau > >> > >
Re: Apache VM for Medic's CouchDB
Would love to see this, thanks for taking the initiative on this Mike! On 6/19/13 7:19 AM, "Andrew Grieve" wrote: >Sounds great! > > >On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau >wrote: > >> Hello everyone, >> >> I have been working the last week on getting medic up and running here >>at >> our office, and so far things are going pretty well. I would like to >>start >> contributing our tests back to the community pretty soon. However, I >> contacted Fil about flowing our test results back to the CI database, >>and >> he informed me that unfortunately the EC2 instance has been removed. >> >> I would like to propose that we have the Apache folks set us up with a >> standard Linux VM that we can use to host the CouchDB server to collect >> test results. Using an Apache VM seems to be more in the Apache spirit >>as >> opposed to an EC2 instance. Since it would be more centralized and >> community owned, it would potentially make it easier for other groups to >> contribute test results. The VM can also serve as a home for any future >> dumps or hosted scripts that we need. >> >> Any thoughts on this? If there are no problems, then can somebody >>involved >> with ASF help me create the relevant INFRA issues? >> >> Thanks, >> Mike Billau >>
Re: CLI: suggested change to "platform ls" command
Great idea to expand the output. I do prefer the explicit `ls` and would rather have the default be --help. Given that, `ls` is harmless, so I don't much mind. On Tue, Jun 18, 2013 at 1:36 PM, Michael Brooks wrote: > I think [1] is up to the command patterns that cordova-cli uses. As far as > I know, it doesn't use any other shortcuted commands. "ls" is not a highly > used command, so a shortcut isn't necessary. > > I think [2] make sense to implement. > > Michael > > > On Tue, Jun 18, 2013 at 10:14 AM, Filip Maj wrote: > > > I had two issues submitted recently, for suggestions to tweaking that > > particular command/api: > > > > [1]: remove the explicit "ls" command > > [2]: have "platform(s)" by itself be the ls command, and expand on what > it > > returns. Not only the currently-installed platforms for a project, but > > also which platforms are available and unavailable to install (I.e. Ones > > where the check_requirements script passes/fails). > > > > Thoughts? > > > > [1] https://issues.apache.org/jira/browse/CB-3903 > > > > [2] https://issues.apache.org/jira/browse/CB-3904 > > > > >
Re: Release Masters?
Sure thing. I'll use 2.9 as a dry run for me. FYI, I updated the broken links in the checklist that were pointing to incubator. -James Jong On Jun 18, 2013, at 3:23 PM, Shazron wrote: > Thanks James! > Most of it is on the wiki, and is pretty straightforward: > Not surprisingly, I made OS X (almost) the same as iOS in structure as > well: http://wiki.apache.org/cordova/IOSReleaseChecklist > Some of the task should be covered in the JIRA issues generated I think. > > > On Tue, Jun 18, 2013 at 10:30 AM, James Jong wrote: > >> Shaz, I haven't done it before but I'll be happy to work with you and help >> when you're out for iOS & OS X. FYI for planning, I will be out & away on >> vacation June 26-July 15. >> -James Jong >> >> On Jun 18, 2013, at 1:18 PM, Andrew Grieve wrote: >> >>> Okay, created a new release bug & sub-tasks here: >>> https://issues.apache.org/jira/browse/CB-3906 >>> >>> If you want to own a component, just assign it to yourself. >>> >>> >>> On Tue, Jun 18, 2013 at 12:33 PM, Shazron wrote: >>> Echoing Fil here. I am the 'lead' for iOS and OS X but anyone can take >> over if they wish. What I'm interested in is who should be the "second" in >> case I can't do it (for example I am away almost all of August). Technically anyone can take over but it will be nice if they are up to speed and >> have the necessary environment to test as a 'second'.. On Tue, Jun 18, 2013 at 9:04 AM, Filip Maj wrote: > I am the "lead" for cordova-js in JIRA that anyone else can take over >> if > they wish. My focus is more on the tooling nowadays. Lots of > features/improvements/wishes in that component.. > > On 6/18/13 9:02 AM, "Marcel Kinard" wrote: > >> On Jun 18, 2013, at 5:07 AM, Brian LeRoux wrote: >> >>> Think we already have this as per the issue tracker concept of >> 'leads' >>> but I do agree formalizing the role a little more would help. >> >> Do all the components leads (as listed in Jira) want to be release >> masters for their components? If not, James Jong and I could probably own >> the "release master" role for a component each, in case any one is >> looking to unload that. > > >> >>
any one going to //build
Any folks going to be at the //build conference in sf next week, hit me up and lets grab a drink or 2. mw
Re: Cordova.js now at 2.9.0rc1 for real
This happened to me back when I upgraded node. I ended up doing rm -rf node_modules and then npm install. I eventually managed to claw my way back to a working Jake. Why it fails utterly silently, and with code 0, puzzles me. Braden On Wed, Jun 19, 2013 at 12:00 PM, Jeffrey Heifetz wrote: > I've been seeing similar issues with Jake since I've upgraded my node and > it is definitely related to Jake failing with dependencies. I have yet to > find the real root cause. > > On 13-06-18 8:27 PM, "Andrew Grieve" wrote: > > >As both Jesse and Shaz pointed out, I ran coho to update cordova.js > >snapshots, but it resulted in them being set to 2.7.0 instead of 2.9.0. > > > >This is now fixed (new commits for 2.9.0rc1), and I've updated the coho > >script to not push by default (so that commits can be inspected). > > > >The root problem is that jake is existing without failure and without > >printing anything to the console. Can anyone else verify if this is > >happening for them? > > > >I debugged it as far as to see that removing the "complainwhitespace" > >dependency from the "hint" task fixed things, but I don't know why that > >is. > > > - > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. >
Re: Cordova.js now at 2.9.0rc1 for real
I've been seeing similar issues with Jake since I've upgraded my node and it is definitely related to Jake failing with dependencies. I have yet to find the real root cause. On 13-06-18 8:27 PM, "Andrew Grieve" wrote: >As both Jesse and Shaz pointed out, I ran coho to update cordova.js >snapshots, but it resulted in them being set to 2.7.0 instead of 2.9.0. > >This is now fixed (new commits for 2.9.0rc1), and I've updated the coho >script to not push by default (so that commits can be inspected). > >The root problem is that jake is existing without failure and without >printing anything to the console. Can anyone else verify if this is >happening for them? > >I debugged it as far as to see that removing the "complainwhitespace" >dependency from the "hint" task fixed things, but I don't know why that >is. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Apache VM for Medic's CouchDB
Sounds great! On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau wrote: > Hello everyone, > > I have been working the last week on getting medic up and running here at > our office, and so far things are going pretty well. I would like to start > contributing our tests back to the community pretty soon. However, I > contacted Fil about flowing our test results back to the CI database, and > he informed me that unfortunately the EC2 instance has been removed. > > I would like to propose that we have the Apache folks set us up with a > standard Linux VM that we can use to host the CouchDB server to collect > test results. Using an Apache VM seems to be more in the Apache spirit as > opposed to an EC2 instance. Since it would be more centralized and > community owned, it would potentially make it easier for other groups to > contribute test results. The VM can also serve as a home for any future > dumps or hosted scripts that we need. > > Any thoughts on this? If there are no problems, then can somebody involved > with ASF help me create the relevant INFRA issues? > > Thanks, > Mike Billau >
Apache VM for Medic's CouchDB
Hello everyone, I have been working the last week on getting medic up and running here at our office, and so far things are going pretty well. I would like to start contributing our tests back to the community pretty soon. However, I contacted Fil about flowing our test results back to the CI database, and he informed me that unfortunately the EC2 instance has been removed. I would like to propose that we have the Apache folks set us up with a standard Linux VM that we can use to host the CouchDB server to collect test results. Using an Apache VM seems to be more in the Apache spirit as opposed to an EC2 instance. Since it would be more centralized and community owned, it would potentially make it easier for other groups to contribute test results. The VM can also serve as a home for any future dumps or hosted scripts that we need. Any thoughts on this? If there are no problems, then can somebody involved with ASF help me create the relevant INFRA issues? Thanks, Mike Billau
Re: Release Masters?
Ideally, all release steps are documented on the Wiki, and all progress made during a release is reported in the release JIRA issues. So, I think you'd get most of the way there by monitoring the issues & commits & read the wiki. If there's anything you're in doubt about, then there's a good chance you're not alone and an email to the list would be great :) On Wed, Jun 19, 2013 at 7:44 AM, Carlos Santana wrote: > Is there any position for something like "Release/Component Apprentice"? > :-) > Just in case a Master wants to train, delegate, have someone to cover for > vacation, or slap :-p, etc.. > > I will be interested to be apprentice since I'm getting started in the > community > --Carlos > > > On Tue, Jun 18, 2013 at 3:23 PM, Shazron wrote: > > > Thanks James! > > Most of it is on the wiki, and is pretty straightforward: > > Not surprisingly, I made OS X (almost) the same as iOS in structure as > > well: http://wiki.apache.org/cordova/IOSReleaseChecklist > > Some of the task should be covered in the JIRA issues generated I think. > > > > > > On Tue, Jun 18, 2013 at 10:30 AM, James Jong > wrote: > > > > > Shaz, I haven't done it before but I'll be happy to work with you and > > help > > > when you're out for iOS & OS X. FYI for planning, I will be out & away > > on > > > vacation June 26-July 15. > > > -James Jong > > > > > > On Jun 18, 2013, at 1:18 PM, Andrew Grieve > wrote: > > > > > > > Okay, created a new release bug & sub-tasks here: > > > > https://issues.apache.org/jira/browse/CB-3906 > > > > > > > > If you want to own a component, just assign it to yourself. > > > > > > > > > > > > On Tue, Jun 18, 2013 at 12:33 PM, Shazron wrote: > > > > > > > >> Echoing Fil here. I am the 'lead' for iOS and OS X but anyone can > take > > > over > > > >> if they wish. What I'm interested in is who should be the "second" > in > > > case > > > >> I can't do it (for example I am away almost all of August). > > Technically > > > >> anyone can take over but it will be nice if they are up to speed and > > > have > > > >> the necessary environment to test as a 'second'.. > > > >> > > > >> > > > >> > > > >> On Tue, Jun 18, 2013 at 9:04 AM, Filip Maj wrote: > > > >> > > > >>> I am the "lead" for cordova-js in JIRA that anyone else can take > over > > > if > > > >>> they wish. My focus is more on the tooling nowadays. Lots of > > > >>> features/improvements/wishes in that component.. > > > >>> > > > >>> On 6/18/13 9:02 AM, "Marcel Kinard" wrote: > > > >>> > > > On Jun 18, 2013, at 5:07 AM, Brian LeRoux wrote: > > > > > > > Think we already have this as per the issue tracker concept of > > > 'leads' > > > > but I do agree formalizing the role a little more would help. > > > > > > Do all the components leads (as listed in Jira) want to be release > > > masters for their components? If not, James Jong and I could > > probably > > > >> own > > > the "release master" role for a component each, in case any one is > > > looking to unload that. > > > >>> > > > >>> > > > >> > > > > > > > > > > > > -- > Carlos Santana > >
Re: Release Masters?
Is there any position for something like "Release/Component Apprentice"? :-) Just in case a Master wants to train, delegate, have someone to cover for vacation, or slap :-p, etc.. I will be interested to be apprentice since I'm getting started in the community --Carlos On Tue, Jun 18, 2013 at 3:23 PM, Shazron wrote: > Thanks James! > Most of it is on the wiki, and is pretty straightforward: > Not surprisingly, I made OS X (almost) the same as iOS in structure as > well: http://wiki.apache.org/cordova/IOSReleaseChecklist > Some of the task should be covered in the JIRA issues generated I think. > > > On Tue, Jun 18, 2013 at 10:30 AM, James Jong wrote: > > > Shaz, I haven't done it before but I'll be happy to work with you and > help > > when you're out for iOS & OS X. FYI for planning, I will be out & away > on > > vacation June 26-July 15. > > -James Jong > > > > On Jun 18, 2013, at 1:18 PM, Andrew Grieve wrote: > > > > > Okay, created a new release bug & sub-tasks here: > > > https://issues.apache.org/jira/browse/CB-3906 > > > > > > If you want to own a component, just assign it to yourself. > > > > > > > > > On Tue, Jun 18, 2013 at 12:33 PM, Shazron wrote: > > > > > >> Echoing Fil here. I am the 'lead' for iOS and OS X but anyone can take > > over > > >> if they wish. What I'm interested in is who should be the "second" in > > case > > >> I can't do it (for example I am away almost all of August). > Technically > > >> anyone can take over but it will be nice if they are up to speed and > > have > > >> the necessary environment to test as a 'second'.. > > >> > > >> > > >> > > >> On Tue, Jun 18, 2013 at 9:04 AM, Filip Maj wrote: > > >> > > >>> I am the "lead" for cordova-js in JIRA that anyone else can take over > > if > > >>> they wish. My focus is more on the tooling nowadays. Lots of > > >>> features/improvements/wishes in that component.. > > >>> > > >>> On 6/18/13 9:02 AM, "Marcel Kinard" wrote: > > >>> > > On Jun 18, 2013, at 5:07 AM, Brian LeRoux wrote: > > > > > Think we already have this as per the issue tracker concept of > > 'leads' > > > but I do agree formalizing the role a little more would help. > > > > Do all the components leads (as listed in Jira) want to be release > > masters for their components? If not, James Jong and I could > probably > > >> own > > the "release master" role for a component each, in case any one is > > looking to unload that. > > >>> > > >>> > > >> > > > > > -- Carlos Santana
