Translation -- Files to translate
Am I correct in assuming that we should only be looking to translate the files from the edge directory? Or should I also bring over some of the specific version files into the crowdin translation system? I'm working on the automated script that compares the github files to those in crowdin and makes sure we have the latest and wanted to make sure I was correct in assuming for now it'd just be edge. (side note: I know that we're going to be moving out some of the documentation from the cordova-docs dir eventually. So we'll have to pull in the plugin specific documentation when the time comes) Thanks for the input, Lisa Lisa Seacat DeLuca Emerging Mobile Software Engineer - IBM Master Inventor SWG Emerging Internet Standards Phone: 1-410-332-2128 | Mobile: 1-415-787-4589 E-mail: ldel...@us.ibm.com personal website: lisaseacat.com Chat: ldel...@us.ibm.com Find me on: and within IBM on: 100 East Pratt St 21-2212 Baltimore, MD 21202-1009 United States
Re: Merge plugin dev branchs into master
Thought of another step! Generate a changelog, and turn it into a blog post so that people will know about the update :) On Thu, Aug 15, 2013 at 4:59 PM, Steven Gill stevengil...@gmail.com wrote: Thanks for the feedback Andrew! Sounds good to me. I am going to go through these steps today. On Thu, Aug 15, 2013 at 12:07 PM, Andrew Grieve agri...@chromium.org wrote: Great! I agree it's time someone take a stab at this! On Thu, Aug 15, 2013 at 3:00 PM, Steven Gill stevengil...@gmail.com wrote: I want to try and flush out the process for merging the dev branches for the core plugins into master and get it onto the wiki. Currently the dev branches have some readme changes, namespace changes and package changes for android. I don't believe any of these changes should be breaking changes. Process 1. Create issue on jira for running mobile spec tests on all platforms using dev branch of plugins 2. Test on all platforms 3. Merge in change into master 4. Publish to plugins.cordova.io? Do we really need to test the plugins on all the platforms for changes that won't affect them at all? I think no. And we should only test plugins that have changes to them (in this case all of them). Should add in bumping of the version number. I think one thing to add to the process is to create mobilespec with the existing versions of plugins, then `cordova plugin rm` them all, then `cordova plugin add` the new ones using a URL that points to the dev branch. aka, test out the upgrade process.
Re: Translation -- Files to translate
Two consideration here I think: 1. Might depend on how the system handles changes to the files. The files within edge/ change pretty regularly, so it would be annoying if for each one-line change the file needed to be entirely re-translated. 2. edge/ gets snapshotted on each release, so if our goal is to have translations done at the time of release, then edge/ will work well. If translations lag behind, it might be better to have the latest stable as the source so that they can be done after a release. On Fri, Aug 16, 2013 at 10:56 AM, Lisa Seacat DeLuca ldel...@us.ibm.comwrote: Am I correct in assuming that we should only be looking to translate the files from the edge directory? Or should I also bring over some of the specific version files into the crowdin translation system? I'm working on the automated script that compares the github files to those in crowdin and makes sure we have the latest and wanted to make sure I was correct in assuming for now it'd just be edge. (side note: I know that we're going to be moving out some of the documentation from the cordova-docs dir eventually. So we'll have to pull in the plugin specific documentation when the time comes) Thanks for the input, Lisa *Lisa Seacat DeLuca* Emerging Mobile Software Engineer - IBM Master Inventor SWG Emerging Internet Standards -- *Phone:* 1-410-332-2128 | *Mobile:* 1-415-787-4589* E-mail:* *ldel...@us.ibm.com* ldel...@us.ibm.com* personal website: **lisaseacat.com* http://lisaseacat.com/* Chat:*[image: Sametime:] ldel...@us.ibm.com * Find me on:* [image: LinkedIn: http://www.linkedin.com/in/lisaseacat]http://www.linkedin.com/in/lisaseacat [image: Twitter: https://twitter.com/IBMlisa]https://twitter.com/IBMlisa *and within IBM on:* [image: IBM Connections: https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-8f4a-2fa7516940c0]https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-8f4a-2fa7516940c0 [image: IBM] 100 East Pratt St 21-2212 Baltimore, MD 21202-1009 United States
Re: icons, splash and hooks
Hey Ivan, All good ideas! Thanks for the feedback. On Thu, Aug 8, 2013 at 2:32 AM, ivan baktsheev dot.and.th...@gmail.comwrote: hello i have some projects which use cordova 2.x and i want to migrate to cordova 3.0. i'm very happy with the project format change and cordova cli, but some issues are very frustrating. 1) icons and splash screens won't copy from res folder i created an after_prepare hook script ( https://gist.github.com/apla/6179863) and assets go to the proper folders. probably, this can be added to the cordova cli. are there any reasons not to include this functionality into cordova? but this added other two issues: We have an outstanding issue to add this feature: https://issues.apache.org/jira/browse/CB-3301 I've added a reference to your gist to it. 2) hook scripts know nothing about current command platform. for example, when i run cordova prepare ios i don't need assets from android copied. i propose to make a hook script reading an environment or the second command line parameter to get a current platform, would that work? https://issues.apache.org/jira/browse/CB-4382 3) hook is not running on windows, and i have to rename my hook to something.js, windows will run this script via cscript.exe. i think, cordova could read the first line of a script file (#!/bin/env node) and launch a proper command, or interpret every hook on windows as a nodejs script; in this case we would be able to get cross-platform hooks. This one is new! Created an issue for it. https://issues.apache.org/jira/browse/CB-4604 thank you! Thank you!
Re: Translation -- Files to translate
Mike Brooks will have some thoughts on this. (He's refactoring the docs generator now.) I just sent him a ping to respond. On Fri, Aug 16, 2013 at 8:06 AM, Andrew Grieve agri...@chromium.org wrote: Two consideration here I think: 1. Might depend on how the system handles changes to the files. The files within edge/ change pretty regularly, so it would be annoying if for each one-line change the file needed to be entirely re-translated. 2. edge/ gets snapshotted on each release, so if our goal is to have translations done at the time of release, then edge/ will work well. If translations lag behind, it might be better to have the latest stable as the source so that they can be done after a release. On Fri, Aug 16, 2013 at 10:56 AM, Lisa Seacat DeLuca ldel...@us.ibm.com wrote: Am I correct in assuming that we should only be looking to translate the files from the edge directory? Or should I also bring over some of the specific version files into the crowdin translation system? I'm working on the automated script that compares the github files to those in crowdin and makes sure we have the latest and wanted to make sure I was correct in assuming for now it'd just be edge. (side note: I know that we're going to be moving out some of the documentation from the cordova-docs dir eventually. So we'll have to pull in the plugin specific documentation when the time comes) Thanks for the input, Lisa *Lisa Seacat DeLuca* Emerging Mobile Software Engineer - IBM Master Inventor SWG Emerging Internet Standards -- *Phone:* 1-410-332-2128 | *Mobile:* 1-415-787-4589* E-mail:* *ldel...@us.ibm.com* ldel...@us.ibm.com* personal website: **lisaseacat.com* http://lisaseacat.com/* Chat:*[image: Sametime:] ldel...@us.ibm.com * Find me on:* [image: LinkedIn: http://www.linkedin.com/in/lisaseacat] http://www.linkedin.com/in/lisaseacat [image: Twitter: https://twitter.com/IBMlisa] https://twitter.com/IBMlisa *and within IBM on:* [image: IBM Connections: https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-8f4a-2fa7516940c0 ] https://w3-connections.ibm.com/profiles/html/profileView.do?key=2e1afd56-daa9-428e-8f4a-2fa7516940c0 [image: IBM] 100 East Pratt St 21-2212 Baltimore, MD 21202-1009 United States
Re: Cordova Committer Hangout notes
Sounds good. Looks like the iOS SDK will be GA/stable at that point too. On Thu, Aug 15, 2013 at 10:55 AM, Andrew Grieve agri...@chromium.orgwrote: Let's try and start the 3.1 release testing first week of sept. It'll be the first release of this new world, so will probably take longer than usual. It'd be good to have it out before PGD EU (on the 24th) On Thu, Aug 15, 2013 at 1:15 PM, Carlos Santana csantan...@gmail.com wrote: Good to know Brian. Then Sep. release might align better with new iOS7 and give more time to make the new shinny more robust On Thu, Aug 15, 2013 at 12:02 PM, Brian LeRoux b...@brian.io wrote: Smart! (Thx Carlos. =) [1] We traditionally have let Aug and December go as that Aug gave us more hardening the new shiny and nobody really works in Dec anyhow. ;) [1] http://www.youtube.com/watch?v=tcGQpjCztgA On Thu, Aug 15, 2013 at 8:34 AM, Carlos Santana csantan...@gmail.com wrote: I think I remember hearing from a very smart person: Shipping in a predictable manner drives adoption, and confidence, in an open source project. Confidence in the health of a project attracts contributors. Committers are our soul, and releases our heartbeat... On Thu, Aug 15, 2013 at 11:28 AM, Carlos Santana csantan...@gmail.com wrote: Forgot to mention during the meeting that there was an Elephant in the hangout. Are we going to have a Cordova Release for this month (August 2013)? --Carlos On Thu, Aug 15, 2013 at 10:50 AM, James Jong wjamesj...@gmail.com wrote: I think u mean The Fancy Pants Podcast? -James Jong On Aug 15, 2013, at 7:23 AM, Carlos Santana csantan...@gmail.com wrote: Thanks for the notes. Great hagout last night it was great meeting everyone. Now that we have the Cordova Blog maybe we should think about The Cordova Podcast :-) --Carlos On Wednesday, August 14, 2013, Brian LeRoux wrote: http://goo.gl/8xL4m8 (LMK if you want access.) -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com
Re: globalization plugin
Finally got around to this. Thanks Ivan! I pulled in your commit! On Wed, Aug 7, 2013 at 6:36 PM, Filip Maj f...@adobe.com wrote: Thanks for submitting the issue and pull request! We'll look into pulling that into the plugin code to get that fixed up. Cheers! Fil On 8/7/13 3:33 PM, Ivan Baktsheev ow...@apla.me wrote: hi everyone! i'm working on a phonegapÂbased project and after migration to the cordova 3.0 i have a few issues. first issue is a globalization plugin. probably nobody is updated plugin to the new call format (args, options = command). so, i fixed it at least for ios and want to make a pull request. my repo: https://github.com/apla/cordova-plugin-globalization jira issue: https://issues.apache.org/jira/browse/CB-4474 tests is passing in emulator. i was signed an ICLA few days ago. how to make a pull request? thank you!
Re: Releases in a 3.0 World
After the discussion on the group hangout + some sleeping, I think we're ready for a proposal... So here it is! - It does *not* propose any changes to our Deprecation policy. That's for another thread (which I'll get to on Monday if no one else does) :) - It does not contain how we store version numbers. That's covered here: http://wiki.apache.org/cordova/StoringRepoVersionsDesign Once we get to a consensus, I'll transfer this to the wiki. Please review comment! There are two kinds of versions: 1. SemVer (www.semver.org) - Used by platforms, plugman, cli 2. CadVer (just made that up :P Cadence Version) - Used by cli, mobile-spec, cordova-js There are two kinds of releases: 1. Patch releases - Pretty much any repo can release a patch release to fix bugs at any time (but should have good reason) 2. Cadence releases - These follow the 10 releases per year, as enumerated on: http://wiki.apache.org/cordova/RoadmapProjects cordova-plugins: - Commit only to the `dev` branch - Use semver for them. - If the version on master is 3.0.0, then the version on dev will start at 3.0.1-dev. - If any commit goes in that add a feature, then change the version on dev to 3.1.0-dev - If any commit goes in that makes an non-backwards-compatible change, then change the version on dev to 4.0.0-dev - Release plugins at most once a week (Thursdays?) - This *does* mean that a change that goes in Wednesday could end up being released the next day. - Release plugins all at the same time so that we can blog the release notes. - Release process: 1. Create a JIRA issue to track the status of the release. a. Comments should be added to this bug after each top-level step below is taken 2. For each plugin that has unreleased commits on their `dev` branch: a. Update its CHANGELOG file with a prettified version of git log b. Update its plugin.xml version by removing the -dev suffix c. Merge dev - master (without pushing) d. Update its plugin.xml version by incrementing the micro and adding -dev (as described above) 3. Combine all plugin changelogs into a Release announcement blog post on cordova-website. a. Steps for this exist in cordova-website's README.md 4. Test a. Create mobilespec using the old versions of plugins b. Perform a plugin upgrade for plugins that have changes (right now, this means doing a `plugin remove` followed by a `plugin add` c. Run through mobilespec, ensuring to do manual tests that relate to changes in the changelog 5. Push! a. Push all branches b. Push the blog post cordova-plugman: - Commit to master always - Release only when necessary. - Release process: 1. For releases that increment the minor or major, email the dev list to let others know about your intent to release (include changelog) a) Wait for at least one +1 2. Increment the version within package.json 3. Update RELEASENOTES.md with the changes for this release 4. Push to npmjs.org * In order to push, you must be given push access to the npm module. * To do so, ask one of the existing module maintainers (listed here: https://npmjs.org/package/plugman) 5. Post a release announcement on the cordova blog (for feature releases only) a. Steps for this exist in cordova-website's README.md b. Not necessary for patch releases, but feature releases should mention significant bugs fixed by previous patch releases. No JIRA: The process is light-weight enough that a JIRA issue isn't necessary for tracking. cordova-cli: - Commit to master, release from release branches (2.9.x, 3.0.x, etc) - Versioned using $COROVA_VERSION-$CLI_VERSION - E.g. 3.0.0-0.5.1 - The first version component is the cadence version, and has its minor incremented whenever the platform repository that it lazy loads by default is changed - E.g. 3.0.0 uses cordova-blackberry@3.0.0, cordova-ios@3.0.0, cordova-android@3.0.0 - E.g. 3.1.0 uses cordova-blackberry@3.1.0, cordova-ios@3.0.1, cordova-android@4.0.0 - E.g. 3.2.0 uses cordova-blackberry@3.1.1, cordova-ios@3.1.0, cordova-android@4.0.1 - E.g. 3.2.1 uses cordova-blackberry@3.1.2, cordova-ios@3.1.0, cordova-android@4.0.1 - The version number of cordova-cli will be the version number that we advertise on our website, blogs docs - Platform version numbers will use semver, and not be referenced - Release process for patch releases: 1. cherry-pick commits from master - latest release branch 2. Increment package.json's micro version 3. Update RELEASENOTES.md 4. Push to npmjs.org * In order to push, you must be given push access to the npm module. * To do so, ask one of the existing module maintainers (listed here: https://npmjs.org/package/cordova) - Release process for minor version - Same as patch release, and in addition: 1. Email the dev list to let others know about your intent to release
Fwd: [jira] [Resolved] (INFRA-6602) Create cordova-medic git repo
Woo! -- Forwarded message -- From: David Nalley (JIRA) j...@apache.org Date: Fri, Aug 16, 2013 at 4:53 PM Subject: [jira] [Resolved] (INFRA-6602) Create cordova-medic git repo To: agri...@chromium.org [ https://issues.apache.org/jira/browse/INFRA-6602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] David Nalley resolved INFRA-6602. - Resolution: Fixed This is now writable. Create cordova-medic git repo - Key: INFRA-6602 URL: https://issues.apache.org/jira/browse/INFRA-6602 Project: Infrastructure Issue Type: Task Security Level: public(Regular issues) Components: Git Reporter: Andrew Grieve Assignee: David Nalley Please create a cordova-medic git repo for the Cordova project. Preferably, importing from: https://github.com/filmaj/medic Otherwise, empty is fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Releases in a 3.0 World
Too much to discuss in one thread, I am starting a new thread to discuss plugin versioning. Cheers, Jesse @purplecabbage risingj.com On Fri, Aug 16, 2013 at 2:41 PM, Andrew Grieve agri...@chromium.org wrote: After the discussion on the group hangout + some sleeping, I think we're ready for a proposal... So here it is! - It does *not* propose any changes to our Deprecation policy. That's for another thread (which I'll get to on Monday if no one else does) :) - It does not contain how we store version numbers. That's covered here: http://wiki.apache.org/cordova/StoringRepoVersionsDesign Once we get to a consensus, I'll transfer this to the wiki. Please review comment! There are two kinds of versions: 1. SemVer (www.semver.org) - Used by platforms, plugman, cli 2. CadVer (just made that up :P Cadence Version) - Used by cli, mobile-spec, cordova-js There are two kinds of releases: 1. Patch releases - Pretty much any repo can release a patch release to fix bugs at any time (but should have good reason) 2. Cadence releases - These follow the 10 releases per year, as enumerated on: http://wiki.apache.org/cordova/RoadmapProjects cordova-plugins: - Commit only to the `dev` branch - Use semver for them. - If the version on master is 3.0.0, then the version on dev will start at 3.0.1-dev. - If any commit goes in that add a feature, then change the version on dev to 3.1.0-dev - If any commit goes in that makes an non-backwards-compatible change, then change the version on dev to 4.0.0-dev - Release plugins at most once a week (Thursdays?) - This *does* mean that a change that goes in Wednesday could end up being released the next day. - Release plugins all at the same time so that we can blog the release notes. - Release process: 1. Create a JIRA issue to track the status of the release. a. Comments should be added to this bug after each top-level step below is taken 2. For each plugin that has unreleased commits on their `dev` branch: a. Update its CHANGELOG file with a prettified version of git log b. Update its plugin.xml version by removing the -dev suffix c. Merge dev - master (without pushing) d. Update its plugin.xml version by incrementing the micro and adding -dev (as described above) 3. Combine all plugin changelogs into a Release announcement blog post on cordova-website. a. Steps for this exist in cordova-website's README.md 4. Test a. Create mobilespec using the old versions of plugins b. Perform a plugin upgrade for plugins that have changes (right now, this means doing a `plugin remove` followed by a `plugin add` c. Run through mobilespec, ensuring to do manual tests that relate to changes in the changelog 5. Push! a. Push all branches b. Push the blog post cordova-plugman: - Commit to master always - Release only when necessary. - Release process: 1. For releases that increment the minor or major, email the dev list to let others know about your intent to release (include changelog) a) Wait for at least one +1 2. Increment the version within package.json 3. Update RELEASENOTES.md with the changes for this release 4. Push to npmjs.org * In order to push, you must be given push access to the npm module. * To do so, ask one of the existing module maintainers (listed here: https://npmjs.org/package/plugman) 5. Post a release announcement on the cordova blog (for feature releases only) a. Steps for this exist in cordova-website's README.md b. Not necessary for patch releases, but feature releases should mention significant bugs fixed by previous patch releases. No JIRA: The process is light-weight enough that a JIRA issue isn't necessary for tracking. cordova-cli: - Commit to master, release from release branches (2.9.x, 3.0.x, etc) - Versioned using $COROVA_VERSION-$CLI_VERSION - E.g. 3.0.0-0.5.1 - The first version component is the cadence version, and has its minor incremented whenever the platform repository that it lazy loads by default is changed - E.g. 3.0.0 uses cordova-blackberry@3.0.0, cordova-ios@3.0.0, cordova-android@3.0.0 - E.g. 3.1.0 uses cordova-blackberry@3.1.0, cordova-ios@3.0.1, cordova-android@4.0.0 - E.g. 3.2.0 uses cordova-blackberry@3.1.1, cordova-ios@3.1.0, cordova-android@4.0.1 - E.g. 3.2.1 uses cordova-blackberry@3.1.2, cordova-ios@3.1.0, cordova-android@4.0.1 - The version number of cordova-cli will be the version number that we advertise on our website, blogs docs - Platform version numbers will use semver, and not be referenced - Release process for patch releases: 1. cherry-pick commits from master - latest release branch 2. Increment package.json's micro version 3. Update RELEASENOTES.md 4. Push to npmjs.org * In order to push, you
