Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cordova Wiki" for change notification.
The "CuttingReleases" page has been changed by AndrewGrieve: http://wiki.apache.org/cordova/CuttingReleases?action=diff&rev1=26&rev2=27 == Steps to Cut a Apache Cordova Release == 0. To keep track of tagging progress and create JIRA issues for each component of a Cordova release, use the [[https://git-wip-us.apache.org/repos/asf?p=cordova-labs.git;a=shortlog;h=refs/heads/jira|JIRA node.js scripts]] (under cordova-labs / jira branch). + 1. Fix all of the created issues (starting with branching & tagging Cordova-JS - see below) 1. Prepare the release candidate using coho. Put online for others to access and download. - 2. Start a VOTE thread on the Cordova mailing list. See http://markmail.org/message/fzmlzbvt3dgdpfrc and http://mail-archives.apache.org/mod_mbox/stdcxx-dev/200601.mbox/%[email protected]%3e for good examples. + 1. Start a VOTE thread on the Cordova mailing list. See http://markmail.org/message/fzmlzbvt3dgdpfrc and http://mail-archives.apache.org/mod_mbox/stdcxx-dev/200601.mbox/%[email protected]%3e for good examples. - 3. People review the release candidate and cast their votes accordingly. See http://www.apache.org/dev/release.html#approving-a-release and http://www.apache.org/dev/release.html#what-must-every-release-contain for things to consider. + 1. People review the release candidate and cast their votes accordingly. See http://www.apache.org/dev/release.html#approving-a-release and http://www.apache.org/dev/release.html#what-must-every-release-contain for things to consider. - 4. A majority of at least three +1 votes from the (P)PMC is needed for the vote to pass. + 1. A majority of at least three +1 votes from the (P)PMC is needed for the vote to pass. - 8. Make the approved release available at http://www.apache.org/dist/incubator/cordova/ ( also see https://dist.apache.org/repos/dist/release/cordova/ ) and update the project website cordova.apache.org to point to the new release. + 1. Make the approved release available at http://www.apache.org/dist/incubator/cordova/ ( also see https://dist.apache.org/repos/dist/release/cordova/ ) and update the project website cordova.apache.org to point to the new release. - 8. Upload the new docs to http://cordova.apache.org/docs, and update the project website (cordova.apache.org) to link to this latest version of the docs. + 1. Upload the new docs to http://cordova.apache.org/docs, and update the project website (cordova.apache.org) to link to this latest version of the docs. - 9. Update the DOAP file at http://svn.apache.org/repos/asf/cordova/site/infra/doap_Cordova.rdf to update the pointer to the latest release. + 1. Update the DOAP file at http://svn.apache.org/repos/asf/cordova/site/infra/doap_Cordova.rdf to update the pointer to the latest release. * Website README.md explains [[https://svn.apache.org/repos/asf/cordova/site/README.md|How to update the docs]] * Website README.md explains [[https://svn.apache.org/repos/asf/cordova/site/README.md|How to compile the site]] - 10. Announce the release to the world! + 1. Announce the release to the world! == Release Philosophy == @@ -71, +72 @@ We have recently, in the past year or so, started tagging Release Candidates about a week before the expected ship for minor release (such as 1.5.0rc1) which tends to tease out more bugs and avoid the embarrassing patch release. (1.4.1 comes to mind.) + === Branching & Tagging Cordova-JS === - === Tagging === - - Creating the first release candidate tag of a release: {{{ - git checkout next + git checkout master - git pull cordova next - git merge --ff-only master # Do this merge only for the first RC of a release. - git tag 2.2.0rc1 # Tag locally on the ''next'' branch - git push cordova next --tag # Push tags + git fetch --tags + git pull + git checkout -b 2.7.x + echo "2.7.0" > VERSION + jake + git commit -am 'Set VERSION to 2.7.0' + git tag 2.7.0rc1 + git push --tags apache 2.7.x }}} + === Tagging === - Tagging subsequent release-candidate tags: - {{{ - git checkout next - git pull cordova next - git tag 2.2.0rc2 - git push cordova master --tag # Push tags - }}} When going through the tagging process, sometimes bugs are found and fixed before the release candidate is even created. In this case, it's fine to change the tags via: {{{ - git checkout next - git pull cordova next - git tag --force 2.2.0rc1 # Re-tag locally + git tag --force 2.7.0rc1 # Re-tag locally git push cordova next --tag # Push tags }}} Once a release is created though (meaning a .zip file has been uploaded), tags should not be changed. + Tagging subsequent release-candidates: - ==== Tagging cordova-js ==== - - First thing is to modify the VERSION file and update it to the new version string. Then: - {{{ - jake - git commit -am 'Tagging x.x.x' - git tag x.x.x - git push --tags apache next + git checkout 2.7.x + git pull apache 2.7.x + git tag 2.7.0rc2 + git push apache 2.7.x --tag # Push tags }}} - Every time you run {{{jake}}}, it grabs the version from the VERSION file and updates any JavaScript files that require the version string appropriately. See the Jakefile for more information on this. + ==== Tagging cordova-docs ====
