This will only be of interest to the project’s maintainers!

This process requires that you have created a file called, for example, maven-settings.xml which contains authentication credentials for pushing to the distribution repository. Example:

<?xml version="1.0"?>
<settings>
  <servers>
    <server>
      <id>sonatype-nexus-snapshots</id>
      <username>user</username>
      <password>...</password>
    </server>
    <server>
      <id>sonatype-nexus-staging</id>
      <username>user</username>
      <password>...</password>
    </server>
  </servers>
</settings>

It also requires that you have the GPG key that is written into the project POM, and that you know its passphrase.

Releasing Maven Artifacts

1. Clone master from the repo: git clone https://github.com/OryxProject/oryx.git
2. If this is a fresh checkout, optionally configure your user name and email for use with git commits, if not already set globally: git config user.name "Your Name" and git config user.email "Your Email"
3. Double-check that tests pass and packaging succeeds first: mvn clean package
4. If this is a new minor release, make a new branch with git branch 2.x.y and push it to all remotes
5. Prepare the release. Consider skipping the (lengthy) tests in these steps with -DskipTests if they’ve been run already. To avoid answering the same question many times, the release and new development versions can be supplied on the command line: mvn -Darguments="-DskipTests" -DreleaseVersion=... -DdevelopmentVersion=... release:prepare
6. Now perform the release. This will require the gpg passphrase for the GPG signing key specified in pom.xml: mvn -s maven-settings.xml -Darguments="-DskipTests -Dgpg.passphrase=..." release:perform
7. Go to https://oss.sonatype.org and Close the Staging Repo, then Release it (and Drop it automatically)

Releasing Binaries

1. Download https://repo1.maven.org/maven2/com/cloudera/oryx/oryx-{batch,speed,serving}/x.y.z/oryx-{batch,speed,serving]-x.y.z.jar
2. Download *.sh from https://github.com/OryxProject/oryx/tree/oryx-x.y.z/deploy/bin
3. Navigate to the Github release that was just created, at https://github.com/OryxProject/oryx/releases/tag/...
4. Edit the title to something more meaningful like Oryx x.y.z
5. Paste brief release notes into the description, including a link to resolved issues for the associated milestone, usually of the form https://github.com/OryxProject/oryx/issues?q=milestone%3A...+is%3Aclosed
6. Attach the Batch, Speed, and Serving layer binaries, and scripts, and save the updated release.

Updating the Site

1. Checkout the release tag if not already: git checkout -f tags/...
2. mvn -DskipTests package
3. mvn site
4. mvn site:stage site:deploy -pl .
5. echo oryx.io > docs/CNAME
6. git add docs
7. git stash
8. git checkout master
9. git stash pop
10. Resolve conflicts in favor of ‘theirs’ changes
11. git add docs (again?)
12. git commit -m "Update site for x.y.z"
13. git push origin master, and if that’s not the main remote, git push upstream master
14. In a minute, check your work at http://oryx.io/