Page History

...

• The process of creating releases has been automated via this release script
• Read and understand the script fully before you execute it. It will cut a Maven release, build binary releases and documentation, then copy the binary artifacts to a staging location on people.apache.org.
• NOTE: You must use git 1.7.X for this or else you'll hit this horrible bug

Rolling Back Release Candidates

• If a release candidate does not pass, it is necessary to roll back the commits which advanced Spark's versioning.

• . Note that you need to configure the script by specifying Apache username, password and your Apache GPG key passphrase. Be careful not to check those in. 
• The script has a number of requirements like maven, jekyll, etc. to be installed and will take a long time to run. For convenience, you can offload the creation to EC2 instance. Please follow instruction later in this section to setup a EC2 instance for creating releases. 
• Read and understand the script fully before you execute it. It will cut a Maven release, build binary releases and documentation, then copy the binary artifacts to a staging location on people.apache.org.
• NOTE: You must use git 1.7.X for this or else you'll hit this horrible bug

Rolling Back Release Candidates

• If a release candidate does not pass, it is necessary to roll back the commits which advanced Spark's versioning.

$ git fetch apache
$ git checkout apache/branch-0.8
$ git tag -d v0.8.1-incubating
$ git push origin :v0.8.1-incubating
$ git revert HEAD --no-edit    # revert dev version commit
$ git revert HEAD~2 --no-edit  # revert release commit
$ git push apache HEAD:branch-0.8

...

• The process of auditing release has been automated via this release audit script
• The release auditor will test example builds against the staged artifacts, verify signatures, and check for common mistakes made when cutting a release
  
  

Setting up EC2 Instance for Preparing and Creating Releases Candidates

• Either you can use the AMI ami-4c721b7c (available is US-West) which has all the necessary tools installed. Or you can create prepare your own instance by the steps given in the Miscellaneous section (see at the end of this document).

• Transfer your GPG keys from your home machine to the EC2 instance

  Code Block
  language bash
  # == On home machine == gpg --list-keys # Identify the KEY_ID of the key you generated gpg --output pubkey.gpg --export <KEY_ID> gpg --output ---export-secret-key <KEY_ID> | cat pubkey.gpg - | gpg --armor --output keys.asc --symmetric --cipher-algo AES256 # Copy keys.asc to EC2 instance   # == On EC2 machine == gpg --no-use-agent --output - keys.asc | gpg --import rm keys.asc

• Edit ~/.m2/settings.xml and specify your Apache user name and password. 

  Code Block
  language xml
  <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <servers> <server> <id>apache.snapshots.https</id> <username>APACHE_USERNAME</username> <password>PASSWORD</password> </server> <server> <id>apache.releases.https</id> <username>APACHE_USERNAME</username> <password>PASSWORD</password> </server> </servers> </settings>

• Download appropriate version of Spark that has the right scripts related to the releases.

Calling a Release Vote

• The release voting happens in two stages. First, a vote takes place on the Apache Spark developers list (the podling PMC or PPMC is voting), then one takes place on the general@i.a.o list (the IPMC). I used the same template for both votes. Look at past vote threads to see how this goes. Once the vote is finished you should also send out a summary e-mail with the totals (subject “[RESULT] [VOTE]...”).
• If possible, attach a draft of the release notes with the e-mail
• Attach the CHANGES.txt file in the e-mail
• NOTE: This will change once we graduate and there will be a single vote
  

...