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:

Software requirement

  • Java 8 or above;
  • Maven 3.5.3 or above;
  • If you’re on Apple Mac OS X, please install GNU TAR, check this post.

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 --full-generate-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.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.
  • Make sure you are working in clean dir.

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 -DskipTests -Dgpg.passphrase=${GPG_PASSPHRASE} deploy


Make sure your can ssh connection to github:

ssh -T

Create a branch for release work from your current development branch, named with this release version, e.g. v2.5.0-release (should not be the same name with the tag name), and then push it to Apache.

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

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. e.g. releaseVersion=2.5.0, developmentVersion=2.5.1-SNAPSHOT, use default tag kylin-2.5.0
$ mvn -DdryRun=true -DskipTests -DreleaseVersion=X.Y.Z -DdevelopmentVersion=(X.Y.Z+1)-SNAPSHOT -Papache-release -Darguments="-Dgpg.passphrase=${GPG_PASSPHRASE} -DskipTests" 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:
  • Remove the .zip.asc.sha256 file as it is not needed.
  • Note that the file names start apache-kylin-.
  • In the source distro .zip, 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.

# Note that if a dry run is done previously, need to do the cleanup first before 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

## Remove the .zip.asc.sha256 file as it is not needed.
$ rm ~/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 sha256 hashes
# (Assumes your O/S has a 'shasum' command.)
function checkHash() {
  cd "$1"
  for i in *.{pom,gz}; do
    if [ ! -f $i ]; then
    if [ -f $i.sha256 ]; then
      if [ "$(cat $i.sha256)" = "$(shasum -a 256 $i)" ]; then
        echo $i.sha256 present and correct
        echo $i.sha256 does not match
      shasum -a 256 $i > $i.sha256
      echo $i.sha256 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 hash of the artifact is as follows: 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 PMC 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
$ mkdir apache-kylin-X.Y.Z
$ cp -rp ../../dev/kylin/apache-kylin-X.Y.Z-rcN/apache-kylin* 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 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.

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-2.5.0-bin.tar.gz.asc --detach-sig apache-kylin-2.5.0-bin.tar.gz
  • Generate the sha256 file for the binary package, e.g,:
shasum -a 256 apache-kylin-2.5.0-bin.tar.gz > apache-kylin-2.5.0-bin.tar.gz.sha256

  on Linux:
  openssl sha256 apache-kylin-2.5.0-bin.tar.gz > apache-kylin-2.5.0-bin.tar.gz.sha256
  • Push the binary package, the signature file and the sha256 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 do update some source code:

  • Merge the release branch, e.g. v2.5.0-release, to the current development branch, e.g. 2.5.x, for preparing the next development iteration.

  • Manually 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 2.5.0 release. 

This is a major release after 2.4, with more than 100 bug fixes and enhancements; All of the changes in this release can be found in:

You can download the source release and binary packages from 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 dataset at sub-second latency in 3 steps:
1. Identify a star schema or snowflake schema data set 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 to everyone who has contributed to the 2.5.0 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.