Apache Olingo Release Documentation


This document describes the release guidelines for Apache Olingo. It heavily refers to standard Apache procedures to release Maven based projects at Apache.

Build Environments

Apache Olingo is built and released with Maven 3 and uses the Apache POM version 16.

Release Artifacts

An Apache Olingo release consists of:

Also the following additional distribution commodity packages are provided as part of the release:

Documentation and JavaDoc

The documentation that will be part of the release must match the code. All examples in the documentation must work. The Java package documentation must be up-to-date. Release independend documentation is maintained on the Apache Olingo Documentation page.


Release Manager

A release manager must be appointed for a release. He or she is in charge of the release process, following the guidelines and eventually generating the release artifacts. The release manager might tailor the process for a specific release.


The Olingo community decides if the release will be a major or a minor release and agrees on a version number.

mvn versions:set -DnewVersion=4.0.0-RC01
find . -name '*.versionsBackup' -type f -delete
git add .
git commit -am '[OLINGO-772] make release - set version 4.0.0-RC01'
git tag -f 4.0.0-RC01

mvn versions:set -DnewVersion=4.1.0-SNAPSHOT
find . -name '*.versionsBackup' -type f -delete
git add .
git commit -am '[OLINGO-772] make release - set version 4.1.0-SNAPSHOT'
git push
git push --tags
Open Issues

There must not be any open JIRA issues for this release. There might be open issues for future releases. Check with: fix for version view

Unit Tests and Integration Tests

All unit tests and integration tests must succeed on a clean machine (starting with an empty local Maven repository). The following Maven execution will run all unit and integration tests:

mvn clean install
Apache License and Code Style

Each source code file must have a current ASF license header. The source code should follow the Apache Olingo code style. For verification run following Maven execution

mvn clean install -Pbuild.quality

NOTICE, LICENSE and DISCLAIMER must be present in all bundles and must be up-to-date.

Remote resources are provided by the ASF and the Maven remote-resources-plugin is configured in the parent pom of the project.


The Maven module odata-dist (in project sub-folder dist) is responsible to package convenience distribution zip files using the assembly plugin. The distributions are created with a release build mvn clean install -Papache-release -Dgpg.passphrase="yourPassphraseHere"

SHA for distribution packages

SHA files are created manually for distribution packages:

gpg --print-md SHA512 ${filename}.zip > ${filename}.zip.sha512

DO NOT create md5 files

Release Tag

A tag has to be created for every release candidate. The naming rule for the tags is ${version}-RCxx. This is created as part of the Maven release process. The tag will be renamed to the final version number upon vote approval.

Release Branch

A branch has to be created for every release. The naming rule for this branch is ${version}. This has to be created manually upon release approval.

Release Candidate

Once all preparations are done, a release candidate will be built.

All release candidates must be cryptographically signed. The string "-RCxx" will be attached to the version number of the release candidate artifacts, where is the number of the release candidate starting with 01. If more than one release candidate is required a new tag has to be created and release candidate number will be increased by one.

The release candidate artifacts:

Once candidate artifacts are available, release manager kicks off the [VOTE process][3].

If the vote fails, the raised issues will be fixed, a new release candidate will be built and the VOTE process will be restarted.

If the release candidate gets approved, we can proceed to release publishing.

How to verify a Release Candidate

This checklist helps verifying if a release candidate is valid:

After all questions of this checklist can be answered with yes it is OK to give a +1 on the mailing list. Of course the Release Manager can also use this checklist to make sure all artifacts are correct before publishing the results on the mailing list.

Publishing the Release

If the release candidate gets approved, we can proceed to release publishing:

Maintain Release Distributions

To maintain the released Distributions for the download pages following steps are required (for more information see Apache Distribution Documentation) to upload the new distribution via SVN (svn co https://dist.apache.org/repos/dist/release/olingo):

Maintain Version Section in DOAP File


Results are shown here:

link text

Additional Apache Release Information

Copyright © 2013-2023, The Apache Software Foundation
Apache Olingo, Olingo, Apache, the Apache feather, and the Apache Olingo project logo are trademarks of the Apache Software Foundation.