cordova-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cordova Wiki] Update of "CuttingReleases" by AndrewGrieve
Date Thu, 18 Apr 2013 19:00:49 GMT
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/%3c43C1C0A0.7040401@roguewave.com%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/%3c43C1C0A0.7040401@roguewave.com%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 ====
  

Mime
View raw message