If you're new to Mesos
See the getting started page for more information about downloading, building, and deploying Mesos.
If you'd like to get involved or you're looking for support
See our community page for more details.
This guide describes the process of doing an official release of Mesos.
Ensure that you have a GPG key or generate a new one, e.g., using
Add your GPG public key to the Apache Mesos dist repository in the KEYS file.
Fetch the svn repository:
svn co https://dist.apache.org/repos/dist/release/mesos
Append your public key using one of methods described in KEYS, e.g.:
(gpg --list-sigs <your name> && gpg --armor --export <your name>) >> KEYS.
Push the commit:
Submit your GPG public key to a keyserver, e.g., MIT PGP Public Key Server.
Add your GPG fingerprint (
gpg --fingerprint <your name>) to your Apache account.
Create a Maven settings file (
~/.m2/settings.xml) for the Apache servers where you must copy your encrypted Apache password which you can get from running
NOTE: You may need to first generate a master password.
<settings> <servers> <server> <id>apache.snapshots.https</id> <username>APACHE USERNAME</username> <password>APACHE ENCRYPTED PASSWORD</password> </server> <server> <id>apache.releases.https</id> <username>APACHE USERNAME</username> <password>APACHE ENCRYPTED PASSWORD</password> </server> </servers> </settings>
gpg-agentto avoid typing your passphrase repeatedly.
Go to Apache JIRA and make sure that the
CHANGELOGfor the release version is up to date.
NOTE: You should move all Unresolved tickets marked with
Target Versionas the release version to the next release version.
PROTIP: Use a JIRA dashboard (example) to track the progress of targeted issues as the release date approaches. This JIRA filter may be useful (
<X.Y.Z>is the release version):
project = MESOS AND "Target Version/s" = <X.Y.Z> AND (fixVersion != <X.Y.Z> OR fixVersion = EMPTY)
bulk editoption in JIRA to move the tickets and make sure to uncheck the option that emails everyone about the move to avoid spamming.
Checkout the correct branch for the release. For regular releases this is the “master” branch. For patch releases this would be the corresponding release branch (e.g., 1.0.x).
Update and commit the
CHANGELOGfor the release.
For regular releases:
Make sure all new API changes, deprecations, major features, and features graduating from experimental to stable are called out at the top of the
CHANGELOG. This JIRA query may be helpful in identifying some of these (
<X.Y.Z>is the release version):
project = MESOS AND "Target Version/s" = <X.Y.Z> AND type = Epic
Ensure that the “Unresolved Critical Issues” section is populated correctly. This JIRA query may be helpful:
project = Mesos AND type = bug AND status != Resolved AND priority IN (blocker, critical)
Prepare a full list of experimental features. The easiest way to do this is to take the list from the previous minor release, remove features that have been declared stable, and those, that declared experimental in the current release. Do not forget to mention features transitioning from experimental to stable in this release at the top of the
NOTE: You should use JIRA to generate the major portion of the
CHANGELOGfor you. Click on the release version in JIRA and click on the
Release Notes. Make sure to configure the release notes in text format.
NOTE: The JIRA Release Notes will list only tickets with
Fix Versionset to that version. You should check for any Resolved tickets that have
Target Versionset but not
Fix Version. Also check for any Unresolved or
Invalidtickets that incorrectly set the
For patch releases update the
CHANGELOGon master branch and then cherry pick onto the release branch.
Ensure version in
CMakeLists.txtis correctly set for the release.
make && support/generate-endpoint-help.pyand commit any resulting changes.
Update and commit
docs/configuration.mdto reflect the current state of the master, agent, and configure flags. If this is a patch release, update it on master branch and then cherry pick onto the release branch.
If this is a regular release, update and commit
docs/upgrades.mdwith instructions about how to upgrade a live cluster from the previous release version to this release version.
If this is a regular release, please ensure that user documentation has been added for any new features.
Make sure that for any updates of the API, specifically the scheduler API, the public mesos protobuf definitions are part of both,
include/mesosas well as
NOTE: This might actually demand code updates if any omissions were identified.
Tagging the Release Candidate
Ensure that you can build and pass all the tests.
$ sudo make -j<cores> distcheck
Run the benchmarks and compare with the previous release for any performance regressions:
$ make bench -j<cores> GTEST_FILTER="*BENCHMARK*"
First tag the required SHA locally.
$ git tag <X.Y.Z-rcR>
X.Y.Zis based on semantic versioning scheme.
Ris release candidate version that starts with 1.
Tag the release externally and deploy the corresponding JAR to the Apache maven repository. It is recommended to use the
support/tag.shscript to accomplish this.
$ ./support/tag.sh X.Y.Z R
NOTE: This script assumes that you have the requisite permissions to deploy the JAR. For instructions on how to set it up, please refer to
NOTE: gnu-sed (Linux) requires
-i''instead of the
-i ''(space-separated) that default OSX uses. You may need to modify your local copy of
tag.shfor it to complete successfully.
If this is a regular release, create a new release branch (
. .x) from this tag.
$ git checkout -b X.Y.x
Now, update master branch to the next minor version in
AC_INIT([mesos], [X.Y.Z])), as well as in
set(MESOS_PATCH_VERSION Z)and then commit.
Voting the Release Candidate
Once a release candidate is deemed worthy to be officially released you should call a vote on the
email@example.com) mailing list.
It is recommended to use the
support/vote.shscript to vote the release candidate.
$ ./support/vote.sh X.Y.Z R
The release script also spits out an email template that you could use to send the vote email.
date -v+3dcommand does not work on some platforms (e.g. Ubuntu), so you may need to fill in the vote end date manually. The vote should last for 3 business days instead of 3 calendar days anyway. Sometimes we allow a longer vote, to allow more time for integration testing.
Preparing a New Release Candidate
If the vote does not pass (any -1s or showstopper bugs), track the issues as new JIRAs for the release.
When all known issues are resolved, update the
CHANGELOGwith the newly fixed JIRAs.
Once all patches are committed to master, cherry-pick them on to the corresponding release branch. This is the same process used for patch releases (e.g., 1.0.2) as well.
$ git checkout X.Y.x $ git cherry-pick abcdefgh...
Now go back up to the “Tagging the Release Candidate” section and repeat.
Releasing the Release Candidate
You should only release an official version if the vote passes with at least 3 +1 binding votes and no -1 votes. For more information, please refer to Apache release guidelines.
It is recommended to use
support/release.shscript to release the candidate.
$ ./support/release.sh X.Y.Z R
The release script also spits out an email template that you could use to notify the mailing lists about the result of the vote and the release.
NOTE: Make sure you fill the email template with the names of binding and non-binding voters.
Update the version in
CMakeLists.txtin the release branch to the next patch version.
Updating the Website
After a successful release, add the information associated with the release in
site/data/releases.yml. It is used to generate the release information on the website.
Update the Getting Started guide to use the latest release link.
Check out the website from svn.
$ svn co https://svn.apache.org/repos/asf/mesos/site mesos-site
Write a blog post announcing the new release and its features and major bug fixes. Include a link to the updated website.
Removing Old Releases from svn
Per the guidelines when to archive, we should only keep the latest release in each version under development.
Checkout the mesos distribution folder:
$ svn co https://dist.apache.org/repos/dist/release/mesos
Remove all minor versions that are no longer under development and commit the change.
Releasing the Version on JIRA
Find the released Mesos version here, and “release” it with the correct release date by clicking on “settings” → “Release”. Also, make sure to add the names of the release managers in “Description” section.
Updating External Tooling
Upload the mesos.interface package to PyPi.
Create/use a PyPi account with access to the mesos.interface submit form. You may need to ask a current package owner to add you as an owner/maintainer.
~/.pypircwith your PyPi username and password.
After a successful Mesos
make(any architecture), cd to
python setup.py registerto register this package.
python setup.py sdist bdist_egg uploadto upload the source distribution and egg for this package.
Update the Mesos Homebrew package.