This guide is for Apache Kylin Committers only.
Shell commands are on Mac OS X as sample.
For people in China, please aware using proxy to avoid potential firewall issue.

Setup Account

Make sure you have avaliable account and privilege for following applications:

Setup GPG signing keys

Follow instructions at to create a key pair
Install gpg (On Mac OS X as sample):
brew install gpg

Generate gpg key:
All new RSA keys generated should be at least 4096 bits. Do not generate new DSA keys
gpg --gen-key

Verify your key:
gpg --list-sigs YOUR_NAME

Get the fingerprint of your key:
gpg --fingerprint YOUR_NAME

It will display the fingerprint like “Key fingerprint = XXXX XXXX …”, then add the fingerprint to your apache account at in “OpenPGP Public Key Primary Fingerprint” field; wait for a few hours the key will added to, for example:

Generate ASCII Amromed Key:
gpg -a --export YOUR_MAIL_ADDRESS > YOUR_NAME.asc &

Upload key to public server:
gpg --send-keys YOUR_KEY_HASH

or Submit key via web:
Open and Submit to (you can pickup any available public key server)

Once your key submitted to server, you can verify using following command:
gpg --recv-keys YOUR_KEY_HASH
for example:
gpg --recv-keys 027DC364

Add your public key to the KEYS file by following instructions in the KEYS file.:
KEYS file location: ${kylin}/KEYS
For example:
(gpg --list-sigs YOURNAME && gpg --armor --export YOURNAME) >> KEYS

Commit your changes.

Prepare artifacts for release

Before you start:

  • Set up signing keys as described above.
  • Make sure you are using JDK 1.7 (not 1.8).
  • Make sure you are using GIT 2.7.2 or above.
  • Make sure you are working on right release version number.
  • Make sure that every “resolved” JIRA case (including duplicates) has a fix version assigned.

Configure Apache repository server in Maven
If you’re the first time to do release, you need update the server authentication information in ~/.m2/settings.xml; If this file doesn’t exist, copy a template from $M2_HOME/conf/settings.xml;

In the “servers” section, make sure the following servers be added, and replace #YOUR_APACHE_ID#, #YOUR_APACHE_PWD#, #YOUR_GPG_PASSPHRASE# with your ID, password, and passphrase:

    <!-- To publish a snapshot of some part of Maven -->
    <!-- To stage a release of some part of Maven -->

    <!-- To publish a website of some part of Maven -->
      <!-- Either

    <!-- To stage a website of some part of Maven -->
      <!-- must match hard-coded repository identifier in site:stage-deploy -->

Fix license issues

# Set passphrase variable without putting it into shell history

# Make sure that there are no junk files in the sandbox
$ git clean -xf
$ mvn clean

# Make sure all unit tests are passed
$ mvn test
# Check the `org.apache.kylin.common.KylinVersion` class, ensure the value of `CURRENT_KYLIN_VERSION` is the release version. 

# Fix any license issues as reported by target/rat.txt
$ mvn -Papache-release -DskipTests -Dgpg.passphrase=${GPG_PASSPHRASE} install

Optionally, when the dry-run has succeeded, change install to deploy:

$ mvn -Papache-release -Dgpg.passphrase=${GPG_PASSPHRASE} deploy

Prepare and dry run a release

Create a release branch named after the release, e.g. v0.7.2-release, and push it to Apache.

$ git checkout -b vX.Y.Z-release
$ git push -u origin vX.Y.Z-release

We will use the branch for the entire the release process. Meanwhile, we do not allow commits to the master branch. After the release is final, we can use git merge --ff-only to append the changes on the release branch onto the master branch. (Apache does not allow reverts to the master branch, which makes it difficult to clean up the kind of messy commits that inevitably happen while you are trying to finalize a release.)

Now, set up your environment and do an optional dry run. The dry run will not commit any changes back to git and gives you the opportunity to verify that the release process will complete as expected.

If any of the steps fail, clean up (see below), fix the problem, and start again from the top.

# Set passphrase variable without putting it into shell history

# Make sure that there are no junk files in the sandbox
$ git clean -xf
$ mvn clean

# Optionally, do a dry run of the release:prepare step, which sets version numbers.
$ mvn -DdryRun=true -DskipTests -DreleaseVersion=X.Y.Z -DdevelopmentVersion=(X.Y.Z+1)-SNAPSHOT -Papache-release -Darguments="-Dgpg.passphrase=${GPG_PASSPHRASE}" release:prepare 2>&1 | tee /tmp/prepare-dry.log

Check the dry run output:

  • In the target directory should be these 8 files, among others:
    • apache-kylin-X.Y.Z-SNAPSHOT-src.tar.gz
    • apache-kylin-X.Y.Z-SNAPSHOT-src.tar.gz.asc
    • apache-kylin-X.Y.Z-SNAPSHOT-src.tar.gz.md5
    • apache-kylin-X.Y.Z-SNAPSHOT-src.tar.gz.sha1
  • Remove the .zip, .zip.asc, .zip.md5 and zip.sha1 file as they are not needed.
  • Note that the file names start apache-kylin-.
  • In the source distro .tar.gz, check that all files belong to a directory called
  • That directory must contain files NOTICE, LICENSE,
  • Check PGP, per this

Run real release:
Now, run the release for real.

# Prepare sets the version numbers, creates a tag, and pushes it to git.
$ mvn -DskipTests -DreleaseVersion=X.Y.Z -DdevelopmentVersion=(X.Y.Z+1)-SNAPSHOT -Papache-release -Darguments="-Dgpg.passphrase=${GPG_PASSPHRASE} -DskipTests" release:prepare

# Perform checks out the tagged version, builds, and deploys to the staging repository
$ mvn -DskipTests -Papache-release -Darguments="-Dgpg.passphrase=${GPG_PASSPHRASE} -DskipTests" release:perform

Close the staged artifacts in the Nexus repository:

Upload to staging area:
Upload the artifacts via subversion to a staging area,

# Create a subversion workspace, if you haven't already
$ mkdir -p ~/dist/dev
$ pushd ~/dist/dev
$ svn co
$ popd

## Move the files into a directory
$ cd target
$ mkdir ~/dist/dev/kylin/apache-kylin-X.Y.Z-rcN
$ mv apache-kylin-* ~/dist/dev/kylin/apache-kylin-X.Y.Z-rcN

## Check in
$ cd ~/dist/dev/kylin
$ svn add apache-kylin-X.Y.Z-rcN
$ svn commit -m 'Upload release artifacts to staging' --username <YOUR_APACHE_ID>

Cleaning up after a failed release attempt:

# Make sure that the tag you are about to generate does not already
# exist (due to a failed release attempt)
$ git tag

# If the tag exists, delete it locally and remotely
$ git tag -d kylin-X.Y.Z
$ git push origin :refs/tags/kylin-X.Y.Z

# Remove modified files
$ mvn release:clean

# Check whether there are modified files and if so, go back to the
# original git commit
$ git status
$ git reset --hard HEAD

Validate a release

# Check unit test
$ mvn test

# Check that the signing key (e.g. 2AD3FAE3) is pushed
$ gpg --recv-keys key

# Check keys
$ curl -O

## Sign/check md5 and sha1 hashes
 _(Assumes your O/S has 'md5' and 'sha1' commands.)_
function checkHash() {
  cd "$1"
  for i in *.{zip,gz}; do
    if [ ! -f $i ]; then
    if [ -f $i.md5 ]; then
      if [ "$(cat $i.md5)" = "$(md5 -q $i)" ]; then
        echo $i.md5 present and correct
        echo $i.md5 does not match
      md5 -q $i > $i.md5
      echo $i.md5 created
    if [ -f $i.sha1 ]; then
      if [ "$(cat $i.sha1)" = "$(sha1 -q $i)" ]; then
        echo $i.sha1 present and correct
        echo $i.sha1 does not match
      sha1 -q $i > $i.sha1
      echo $i.sha1 created
$ checkHash apache-kylin-X.Y.Z-rcN

Apache voting process

Vote on Apache Kylin dev mailing list
Release vote on dev list, use the commit id that generated by Maven release plugin, whose message looks like “[maven-release-plugin] prepare release kylin-x.x.x”:

Subject: [VOTE] Release apache-kylin-X.Y.Z (RC[N])

Hi all,

I have created a build for Apache Kylin X.Y.Z, release candidate N.

Changes highlights:

Thanks to everyone who has contributed to this release.
Here’s release notes:

The commit to be voted upon:

Its hash is xxx.

The artifacts to be voted on are located here:

The hashes of the artifacts are as follows:
src.tar.gz.md5 xxx
src.tar.gz.sha1 xxx

A staged Maven repository is available for review at:

Release artifacts are signed with the following key:

Please vote on releasing this package as Apache Kylin X.Y.Z.

The vote is open for the next 72 hours and passes if a majority of
at least three +1 PPMC votes are cast.

[ ] +1 Release this package as Apache Kylin X.Y.Z
[ ]  0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...

Here is my vote:

+1 (binding)

After vote finishes, send out the result:

Subject: [RESULT] [VOTE] Release apache-kylin-X.Y.Z (RC[N])

Thanks to everyone who has tested the release candidate and given
their comments and votes.

The tally is as follows.

N binding +1s:

N non-binding +1s:

No 0s or -1s.

Therefore I am delighted to announce that the proposal to release
Apache-Kylin-X.Y.Z has passed.


Publishing a release

After a successful release vote, we need to push the release
out to mirrors, and other tasks.

In JIRA, search for
all issues resolved in this release,
and do a bulk update changing their status to “Closed”,
with a change comment
“Resolved in release X.Y.Z (YYYY-MM-DD)”
(fill in release number and date appropriately).
Uncheck “Send mail for this update”.

Mark the version released in JIRA system, Manage Versions.

Promote the staged nexus artifacts.

  • Go to and login
  • Under “Build Promotion” click “Staging Repositories”
  • In the line with “orgapachekylin-xxxx”, check the box
  • Press “Release” button

Check the artifacts into svn.

# Get the release candidate.
$ mkdir -p ~/dist/dev
$ cd ~/dist/dev
$ svn co

# Copy the artifacts. Note that the copy does not have '-rcN' suffix.
$ mkdir -p ~/dist/release
$ cd ~/dist/release
$ svn co
$ cd kylin
$ cp -rp ../../dev/kylin/apache-kylin-X.Y.Z-rcN apache-kylin-X.Y.Z
$ svn add apache-kylin-X.Y.Z

# Check in.
svn commit -m 'checkin release artifacts'

Svnpubsub will publish to and propagate to within 24 hours.

If there are now more than 2 releases, clear out the oldest ones:

cd ~/dist/release/kylin
svn rm apache-kylin-X.Y.Z
svn commit -m 'Remove old release'

The old releases will remain available in the
release archive.

Release same version in JIRA, check Change Log for the latest released version.

Build and upload binary package

After publish the release, you need generate the binary packages and then put them to the svn release repository;

  • Do git fetch --all --prune --tags to sync your local repo with remote.
  • Git checkout the tag for current release;
  • Make a binary package by refering to this doc;
  • Sign the generated binary package with gpg, e.g,:
gpg --armor --output apache-kylin-1.5.0-bin.tar.gz.asc --detach-sig apache-kylin-1.5.0-bin.tar.gz
  • Generate the md5 file for the binary package, e.g,:
md5sum < apache-kylin-1.5.0-bin.tar.gz > apache-kylin-1.5.0-bin.tar.gz.md5
  • Push the binary package, the signature file and the md5 file to the svn dev repo, then run svn mv <files-in-dev> <files-in-release> to move them to svn release repo.
  • For different Hadoop/HBase version, you may need repeat the above steps;
  • Add the files and then commit the svn changes.

Update source code

After publish the release, you need to manually update some source code:

  • Update KylinVersion class, change value of CURRENT_KYLIN_VERSION to current development version.

Publishing the web site

Refer to How to document for more detail.

Send announcement mail to mailing list

Send one mail with subject like “[Announce] Apache Kylin x.y.z released” to following list:

  • Apache Kylin Dev mailing list:
  • Apache Kylin User mailing list:
  • Apache Announce mailing list:
    Please notice to always use your Apache mail address to send this;

Here is a sample of announcement email (by studying Kafka’s):

The Apache Kylin team is pleased to announce the immediate availability of the x.y.z release. 

This is a bug fix release based on; All of the changes in this release can be found in:

You can download the source release and binary packages from

More information about the binary packages is on Apache Kylin's download page

Apache Kylin is an open source Distributed Analytics Engine designed to provide SQL interface and multi-dimensional analysis (OLAP) on Apache Hadoop, supporting extremely large datasets.

Apache Kylin lets you query massive data set at sub-second latency in 3 steps:
1. Identify a Star Schema data on Hadoop.
2. Build Cube on Hadoop.
3. Query data with ANSI-SQL and get results in sub-second, via ODBC, JDBC or RESTful API.

Thanks everyone who have contributed to the x.y.z release.

We welcome your help and feedback. For more information on how to
report problems, and to get involved, visit the project website at


This guide drafted with reference from Apache Calcite Howto doc, Thank you very much.