Before creating a release, ensure that:

Apache releases are posted to, which is a Subversion repository.

We have two directories there, check out these:


svn co apache-dist-release-gobblin
svn co apache-dist-dev-gobblin

When working with these directories, make sure you are working with the correct one, otherwise you may be publishing pre-release artifacts to the global release mirror network!

GPG keys

The release manager must have a GPG key to be used to sign the release. You should pre-install gpg tool. The steps here also assume you have the following set (not using whoami if that’s not appropriate):


If you have an existing GPG key, but it does not include your Apache email address, you can add your email address as described in this posting. Otherwise, create a new GPG key giving your Apache email address, using gpg --gen-key then gpg --export-key $GPG_KEY > my-apache.key and gpg --export-secret-key -a $GPG_KEY > my-apache.private.key in the right directory (~/.ssh is a good one). For ease of this tutorial, let us assume you export your private key as: gpg --export-secret-key > ~/.gnupg/secring.gpg 

Upload your GPG public key (complete with your Apache email address on it) to a public keyserver - e.g. run gpg --export --armor $GPG_KEY and paste it into the “submit” box on

Look up your key fingerprint with gpg --fingerprint $GPG_KEY - it’s the long sequence of hex numbers separated by spaces. Log in to then copy-and-paste the fingerprint into “OpenPGP Public Key Primary Fingerprint”. Submit.

Now add your key to the apache-dist-release-gobblin/KEYS file:

cd apache-dist-release-gobblin

(gpg --list-sigs $ && gpg --armor --export $ >> KEYS
svn --username $SVN_USERNAME --no-auth-cache commit -m "Update gobblin/KEYS for $GPG_KEY"


Once you have followed these instructions, you should have: 

Gradle setup

Configure gradle: edit the file ~/.gradle/ and make sure you have the following setup: 

# Maven Signing




# Nexus Access



The GPG key ID can be found by running gpg --list-keys --keyid-format SHORT

Code Validation

Before releasing, you should run a full build to check if all the tests are passing. You can do that by running: 

./gradlew build

If this builds successfully then it means the tests pass and the code is well formatted. But, it doesn't mean that all license headers are in place.

Verify License

We must run checks to ensure that the files have proper license headers. These license checks can be run by executing:

./gradlew rat

You should open the report at build/rat/rat-report.html to validate that all files that are in scope (i.e. not excluded) have the appopriate headers. Running the rat task to generate this report is quick and does not runs other tests. See HEADER for the contents of the license header. These contents should appear at the top of the file as a comment. If a file or set of files needs to be excluded or included from Rat validation, you can update the Rat exclusion list in build.gradle.


Update the file by adding details about the new version. This is a manual process, and you will have to go through all the JIRAs that are part of this release to summarize highlights, new features, enhancements and bugs. 

The existing CHANGELOG's format is self explanatory, so we will not go in depth about it. 

Update JIRAs

Update JIRAs to specify fixVersion (which is current release version). You can either do it manually for each JIRA, or use the custom tool that we have for this purpose: 


This tool will ask you for the fixVersion that you want to apply on all the JIRAs that do not have a fixVersion and are in resolved or fixed state. Assuming you are making a release for x.y.z, your fixVersion input would be x.y.z


  1. This operation can take time (in order of few minutes). The tool is simple enough, so you can also tweak it for your custom requirements. 
  2. JIRAs that are in 'closed' state cannot be edited, so you might hit 'unauthorized exception'. If you encounter such JIRA, please reopen that JIRA and 'resolve' it instead. 

Create a branch for release

Assuming that you are preparing to release version x.y.z from the current commit, then create a branch with:

git checkout -b x.y.z
git push origin x.y.z

Reserve new version for next release

Update the version in in master branch. Eg: 


Also, if not done already create a new version in using JIRA administration dashboard. You can specify the start date as of today and leave the end date as blank. 

Create a Release

The following steps will build a tarball suitable for an ASF source release. This also generates accompanying MD5 and ASC files.

First, clean any files unknown to git (WARNING: this removes all untracked files, including those listed in .gitignore, without prompting):

git clean -fdx

Alternatively, you can make a fresh clone of the repository to a separate directory:

git clone gobblin-release
cd gobblin-release

To generate the source release, run:

./gradlew clean release -Prelease=true

This generates a source tarball. The -Prelease=true setting prevents -SNAPSHOT from being appended to the version, which is the default behavior. It also prevents any builds from the extracted source tarball from including -SNAPSHOT in the version. It achieves this by modifying within the generated archive.

To generate the convenience binary, run:

./gradlew build -x findbugsMain -x test -x rat -x checkstyleMain

The source and binary tarball needs to be signed. You can do this either manually or automatically. If you have configured your key information in your then your archive should automatically be signed. There should now be a corresponding ASC file alongside the tarball and MD5 file. Otherwise you'll need to sign it manually by running:

gpg --sign --armor --detach-sig build/distribution/source/apache-gobblin-sources-*.tgz
gpg --sign --armor --detach-sig build/gobblin-distribution/distributions/apache-gobblin-bin-*.tar.gz

Upload the Release

You should make the release candidate available in For example, if you are releasing release candidate RC0 for version x.y.z then you should upload the source distribution files to:

To create a release folder and to check it out (be sure to substitute x.y.z for the actual version), run the following:

svn mkdir
svn co apache-gobblin-x.y.z-rc0
cd apache-gobblin-x.y.z-rc0

Verify that the sha512 signature in the file matches the output of the command:

shasum -a 512 apache-gobblin-sources-0.15.0.tgz 

You could then add the source and binary release as described above and commit. 

Tag the release

You should tag the release candidate in git. Assuming you are releasing release candidate RC0 for version x.y.z then you can attach a tag to the current commit with:

git tag -s release-x.y.z-rc0 -m 'Apache Gobblin x.y.z RC0'

Then push the tag:

git push origin release-x.y.z-rc0

Note: If on Mac, you might also need to do this: 

brew install pinentry-mac

export GPG_TTY=$(tty)

Staging artifacts in Nexus

General information on publishing to Maven can be found here. To build and upload the archives to the Apache Nexus staging repository, run:

./maven-nexus/ -remote 

Note that if you are running the above command from the source archive, then you don't need -Prelease=true. The above command assumes you have configured ~/.gradle/ with your GPG key information.

If you now visit the Apache Nexus Repository and click on Staging Repositories, you should see a repository named orgapachegobblin-xxxx, where xxxx is some number. Select the repository and browse the content to make sure the set of files looks right. If it looks correct then Close the repository. The repository is now ready for use. If you look at the summary there is a URL for the repository that may be used to fetch the archives.

Let's suppose you have a Gradle project you'd like to use to test Gobblin. You can add the URL for the Staging Repository to your build.gradle like this:

repositories {
  maven {
    url ''

You could also visit the Staging Repository URL in your browser and download the artifacts.

Once the artifacts have been verified, you need to close the Gobblin staging repository. You need to be logged into the Nexus repository to be able to close the repo. You should see a Close button on the top. When you click on the button, it should prompt you for a description. Enter "Apache Gobblin 0.x.y RCz" (substitute the right values for x,y, and z), and click "Save".  

Call for a vote to release

At this point you should have:

  1. Published a source release
  2. Staged artifacts in Nexus built from source

Now you can call a vote in the Gobblin dev mailing list for release. Look in the archives for previous votes for an example..

Here is a sample call for vote email: Mail Archive 

Note: You should allow for a minimum of 72 hours voting period. 

After waiting, if the vote passed. Send a result email. Eg.: Mail Archive

Publishing the Release

Once the vote has passed, you can publish the source release and artifacts.


The Gobblin source release are checked into SVN under

To see all the previous releases, run:

svn list

Promote the release candidate by moving it from dev svn to release by running (replace x.y.z with the release number):

svn mv

Within 24 hours they will be distributed to the mirrors. Then it should be available for download at


To distribute the artifacts, simply select the staged repository for Gobblin that you prepared in Nexus and chooose Release. They should then be available within the next day or so in the central repository.


Update the tag

git tag -s release-x.y.z -m 'Apache Gobblin x.y.z'

Then push the tag:

git push origin release-x.y.z

Release on Github

After pushing the git tag, create a Github release to update the repository's packages and generate tagged Docker images.

Documentation for releasing on Github can be found here:

Update the Website

Note: Website is in separate repository, if not already checked-out, checkout separately.

First, clean any files unknown to git (WARNING: this removes all untracked files, including those listed in .gitignore, without prompting):

git clean -fdx

Alternatively, you can make a fresh clone of the repository to a separate directory:

git clone gobblin-site-release
cd gobblin-site-release

Modify navigation.html

  1. Search for "Release Step 1" string in navigation.html file, and follow the html comment instruction to add a li html tag for new release (in same format as exists in the html code). 
  2. Search for "Release Step 2" string in index.html file under download dir, and follow the html comment instruction to add a div html tag for new release (in same format as exists in the html code).
  3. Open index.html in your browser locally and verify all links work. 

Commit and push the changes to git. 

Announce the Release

Send an ANNOUNCE email to Gobblin dev mailing list (, and

Example: Mail Archive 

  • No labels