How to create and announce a Karaf release.

Required tools, practices and resources

  • Use Maven 3.0.4 or greater.
  • JDK 1.5 if version < 2.3.0, JDK 1.7 otherwise.
  • Install princexml 7.1 for manual generation.
  • Each and every release must be SIGNED
  • Your public key should also be cross-signed by other Apache committers (not required, but suggested)
  • Make sure you have all Apache servers defined in your settings.xml
  • Git client 1.8 or greater


Sample versioning:

1.0.0-SNAPSHOT 1.0.0
1.1.0-SNAPSHOT 1.1.0
1.1.1-SNAPSHOT 1.1.1
1.1.2-SNAPSHOT 1.1.2
2.0.0-SHAPSHOT 2.0.0


To prepare and perform a release you must be at least at Apache Karaf Committer.

Your settings.xml should look like:

        <gpg.passphrase> <!-- YOUR KEY PASSPHRASE --> </gpg.passphrase>
    <!-- To publish a snapshot of some part of Maven -->
      <username> <!-- YOUR APACHE USERNAME --> </username>
      <password> <!-- YOUR APACHE PASSWORD --> </password>
    <!-- To stage a release of some part of Maven -->
      <username> <!-- YOUR APACHE USERNAME --> </username>
      <password> <!-- YOUR APACHE PASSWORD --> </password>
    <!-- To deploy the manual -->
        <username> <!-- YOUR APACHE USERNAME --> </username>
        <password> <!-- YOUR APACHE PASSWORD --> </password>

Your git environment should have your,, and user.password set.

Community awareness message(s).

In the lead up towards a release candidate the user base should be given some notification.

In the case of dot zero release a new maintenance branch may be created with trunk continuing new development. The maintenance branch may be used for stabilization of the code base before a release candidate is cut. A notification message to the dev & user lists may be warranted.

To: "Karaf Developers List" <>
Subject: [NOTICE] Karaf trunk branched to create X.Y.0 maintenance branch. 


We've just branched off X.Y.0 from trunk and started to stabilize it; latest artifacts are
available via apache-snapshot repo... simply add the following repo to your pom,
change the version to and provide us with feedback.

<<insert short description of the reason for branching here>>


-The Karaf team

A few weeks later the following message would be sent:

To: "Karaf Developers List" <>
Subject: [UPDATE] Karaf X.Y.0 release branch status.


Thanks for all your feedback; we've fixed XX bugs/problems on the release branch
and will start a release about next week; Thanks again for all your contributions.

-The Karaf Team

Staging the Release Candidate

  1. Grab the latest source
    git clone
  2. Prepare your POMs for release:
    1. make sure there is no snapshots in the POMs to be released
    2. make sure everything builds fine
    3. check that your POMs will not lose content when they are rewritten during the release process:
      mvn release:prepare -Pmanual -DdryRun

      Please diff the original pom.xml with the one named pom.xml.tag to see if the license or any other info has been removed. This has been known to happen if the starting <project> tag is not a single line. The only things that should be different between these files are the <version> and <scm> elements. If there are any other changes, you must fix the original pom.xml file and commit before proceeding with the release.

    4. publish a snapshot
      $ mvn deploy
      [INFO] [deploy:deploy]
      [INFO] Retrieving previous build number from apache.snapshots.https
    • If you experience an error during deployment like a HTTP 401 check your settings for the required server entries as outlined in the Prerequisites
    • Be sure that the generated artifacts respect the Apache release rules: NOTICE and LICENSE files should be present in the META-INF directory within the jar. For sources artifacts, be sure that your POM does not use the maven-source-plugin:2.0.3 which is broken. The recommended version at this time is 2.0.4
    • You should verify the deployment under the snapshot repository on Apache
  3. Prepare the release
    mvn release:clean
    mvn release:prepare -Pmanual

    Note: If you encounter the error message: "authorization failed: Could not authenticate to server : rejected Basic challenge" then try the following command:

    mvn release:prepare -Pmanual -Dusername=[username] -Dpassword=[password]
  4. Stage the release for a vote
    mvn release:perform -Pmanual
    • The release will automatically be inserted into a temporary staging repository for you, see the Nexus staging documentation for full details
    • You can continue to use mvn release:prepare and mvn release:perform on other sub-projects as necessary on the same machine and they will be combined in the same staging repository
  5. Close the staging repository
    • Login to using your Apache credentials. Click on Staging on the left. Then click on org.apache.karaf in the list of repositories. In the panel below you should see an open repository that is linked to your username and IP. Right click on this repository and select Close. This will close the repository from future deployments and make it available for others to view. If you are staging multiple releases together, skip this step until you have staged everything
  6. Verify the staged artifacts
    • If you click on your repository, a tree view will appear below. You can then browse the contents to ensure the artifacts are as you expect them. Pay particular attention to the existence of *.asc (signature) files. If you don't like the content of the repository, right click your repository and choose Drop. You can then rollback your release (see Canceling the Release) and repeat the process
    • Note the staging repository URL (especially the number at the end of the URL) you will need this in your vote email
  7. Upload the manual
    cd manual ; mvn scalate:deploy
  8. Update the web site with the following:
    • add a news section on the website at src/main/webapp/index/community/news/ and a link to it in src/main/webapp/ (only keep a few news on that one) and src/main/webapp/index/community/
    • add the new schemas (if any) in src/main/webapp/xmlns
    • create a page for the release in src/main/webapp/download/karaf-xxx-release with the release notes and jira issues
    • update dependencies table src/main/webapp/index/documentation/karaf-dependencies
    • update the download page in src/main/webapp/ to point to that page (only the latest of it branch should appear on the download page)
    • move the older version of the same branch to the src/main/webapp/download/ page
    • update the documentation page with src/main/webapp/ to point to the latest manual and schemas
    • commit the changes
    • ?? should we do that in a branch and merge it later to trunk when the release is published, still need to be discussed related to how / if we maintain branches for the website ??
    • ?? maybe include a pointer to the website trunk or branch in the vote email so that people can check the future website / release notes ??
    • Website update on site project, execute mvn clean install scm-publish:publish-scm -Dusername= -Dpassword=

Starting the vote

Propose a vote on the dev list with the closed issues, the issues left, and the staging repository - for example:

To: "Karaf Developers List" <>
Subject: [VOTE] Release Karaf version X.Y.Z


We solved N issues in this release:

There are still some outstanding issues:

Staging repository:[YOUR REPOSITORY ID]/

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.
  • To get the JIRA release notes link, browse to the Karaf JIRA page, select Release Notes and choose the release and format (HTML)
  • To get the list of issues left in JIRA, select the Open Issues tab on the main Karaf page.

Wait for the Results

From Votes on Package Releases:

Votes on whether a package is ready to be released follow a format similar to majority approval - except that the decision is officially determined solely by whether at least three +1 votes were registered. Releases may not be vetoed. Generally the community will table the vote to release if anyone identifies serious problems, but in most cases the ultimate decision, once three or more positive votes have been garnered, lies with the individual serving as release manager. The specifics of the process may vary from project to project, but the 'minimum of three +1 votes' rule is universal.

The list of binding voters is available at

If the vote is successful, post the result to the dev list - for example:

To: "Karaf Developers List" <>
Subject: [RESULT] [VOTE] Release Karaf version X.Y.Z


The vote has passed with the following result :

  +1 (binding): <<list of names>>
  +1 (non binding): <<list of names>>

I will copy this release to the Karaf dist directory and
promote the artifacts to the central Maven repository.
  • If the vote is unsuccessful, you need to fix the issues and restart the process - see Canceling the Release.
  • If the vote is successful, you need to promote and distribute the release - see Promoting the Release.

Canceling the Release

If the vote fails, or you decide to redo the release:

  1. remove the release tag from Git (git tag -d ...)
  2. login to using your Apache credentials. Click on Staging on the left. Then click on org.apache.karaf in the list of repositories. In the panel below you should see a closed repository that is linked to your username and IP (if it's not yet closed you need to right click and select Close). Right click on this repository and select Drop.
  3. rollback the version in the pom.xml and commit any fixes you need to make

Promoting the Release

If the vote passes:

  1. copy the released artifacts to the Karaf dist directory (/x1/www/ on
  2. delete the old release from the Karaf dist directory (it's archived)
  3. login to with your Apache credentials. Click on Staging. Find your closed staging repository, right click on it and choose Promote. Select the Releases repository from the drop-down list and click Promote.
  4. next click on Repositories, select the Releases repository and validate that your artifacts are all there
  5. deploy the updated web site

For the last task, it's better to give the mirrors some time to distribute the uploaded artifacts (one day should be fine). This ensures that once the website (news and download page) is updated, people can actually download the artifacts.

Update JIRA

Go to Admin section on the Karaf JIRA and mark the X.Y.Z version as released - create version X.Y.Z+1, if that hasn't already been done.

Update dist

Apache Dist use scm pubsub system to publish the released artifact to different mirrors.

The Karaf (and subprojects) dist pubsub location is on svn:

In order to publish the release artifacts, you have to commit in this svn location. It will trigger the sync of dist mirrors.

Announcing the Karaf Release

To: "Karaf Users List" <>
Subject: [ANN] Apache Karaf version X.Y.Z Released

The Apache Karaf team is pleased to announce the release of Karaf version X.Y.Z

Apache Karaf is a small OSGi distribution which provides a ready to use container for server side applications.

<<insert short description of important updates>>

This release is available from and Maven:


Release Notes:

<<insert release notes in text format from JIRA>>


-The Apache Karaf team

Remember to forward this announcement to - try not to cross-post (CC announcements to both user and dev lists).

Send an announce to

Send the same announce but without the detailed release notes from JIRA to from an email address.