This document describes the release guidelines for Apache Olingo. It heavily refers to standard Apache procedures to release Maven based projects at Apache.
Apache Olingo is built and released with Maven 3 and uses the Apache POM version 16.
An Apache Olingo release consists of:
org.apache.olingo
in the Apache Maven Repository.
In detail the following artifacts are produced for each release module:
<artifactId>-<version>.<ext>
<artifactId>-<version>-sources.<ext>
<artifactId>-<version>-javadoc.<ext>
<artifactId>-<version>.pom
Also the following additional distribution commodity packages are provided as part of the release:
Olingo-OData-${version}-source-release.${ext}
Olingo-OData-JavaDoc-${version}-javadoc.${ext}
Olingo-OData-Server-for-Java-${version}-lib.${ext}
Olingo-OData-Client-for-Java-${version}-jpa.${ext}
Olingo-OData-Client-for-Android-${version}-lib.${ext}
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.
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
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
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
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.
<resourceBundle>org.apache:apache-jar-resource-bundle:1.4</resourceBundle>
<resourceBundle>org.apache:apache-disclaimer-resource-bundle:1.1</resourceBundle>
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 files are created manually for distribution packages:
gpg --print-md SHA512 ${filename}.zip > ${filename}.zip.sha512
DO NOT create md5 files
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.
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.
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.
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.
If the release candidate gets approved, we can proceed to release publishing:
mvn deploy -Papache-release
into the Staging AreaTo 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
):
svn co https://dist.apache.org/repos/dist/release/olingo
odata2
, odata4
, ...)rel-x.x.x
) and copy all distribution artifacts (includes .zip, .asc, .md5, .sha512).svn add rel-x.x.x
) and do the commit (e.g svn ci -m "Added Olingo x.x.x release"
)https://olingo.apache.org/doap_Olingo.rdf
Results are shown here:
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.