This document outlines how to create a new release of RDF4J.
The simple way: using the release script
In the project root, the script release.sh is a shell-script that (almost) fully automates the handling of releases. It creates branches, sets correct version numbers, builds and uploads artifacts, etc. It gives you several prompts along the way to guide you through the process.
The release script should always be run from the master branch.
If for whatever reason, you wish to manually create a release instead, the following sections detail the manual process.
Patch releases are created by branching the master branch into a release branch, and
when complete, tagging this release branch with the version number before
release deployment. Once release deployment is complete, the release branch
IMPORTANT: the master branch is always in a release ready state (build
passes, no new features, docs are up to date), so a patch release from the
master branch can be done in an ad-hoc fashion, without the need for a formal
Plans to do a patch release are announced by the project lead on the
usually about a week in advance, with an open invitation for contributors to
propose additional fixes to include, which are done as Pull Requests to the
Creating a patch release branch
Any fixes to be included in a patch release must be merged into the master
branch first. A patch release branch should differ from the master branch,
at the time of release, only by the version number - a patch release branch has
a patch number version, while the master branch has a SNAPSHOT version. To
create a patch release branch, follow these steps:
Check out the master branch.
E.g. if we’re preparing a release 2.2.1, the master branch will have the version 2.2.1-SNAPSHOT:
git checkout master
Create a new release branch, named releases/<version>:
git checkout -b releases/2.2.1
Fix maven version numbers in the release branch. We need to set the project version to 2.2.1 by using:
This will ask for the new version number. Enter 2.2.1 to indicate that this is the 2.2.1 release.
After this is done, execute
which will remove backup files.
Finally, commit the version number changes:
git commit -s -a -m "release 2.2.1"
Tag the version and push the tag upstream:
git tag 2.2.1 git push origin 2.2.1
NOTE: The release branch itself is usually not pushed upstream - you only use it locally to prepare the commit that sets the pom version numbers for the release. Also, the branch is not merged back into the master branch (because we want to keep the SNAPSHOT version number on the master branch). Once you pushed the tag, you can delete your local branch.
Finally, prepare the master branch for the next iteration:
git checkout mastermvn versions:set and enter 2.2.2-SNAPSHOT as the new snapshot number
mvn versions:commitgit commit -s -a -m "next development iteration"git push
Hotfix release are patch releases that target a prior minor version (not the
latest stable release). These are needed when a critical bug was found in a
production deployment using an earlier version.
A hotfix release use a preceding release as its basis. This means we need to create a release branch not by simply branching from the current master branch, but by branching from a specific release tag. To create a patch release branch, follow these steps:
Check out the tag of the previous release. E.g. if we’re preparing a release 2.1.6, the preceding release is 2.1.5, so we do:
git checkout 2.1.5
Create a new release branch, named releases/<version>:
git branch releases/2.1.6
Fix maven version numbers in the release branch. We need to set the project version to 2.1.6-SNAPSHOT by using:
This will ask for the new version number. Enter 2.1.6-SNAPSHOT to indicate that this is the development branch for the upcoming 2.1.6 release. After this is done, execute
which will remove backup files. Finally, commit the version number changes:
git commit -s -a -m "release branch for 2.1.6"
Push the newly created branch, as follows:
git push origin releases/2.1.6
Bug fixes are typically added to a hotfix release branch by cherry-picking the relevant commits from the master branch.
This works as follows:
Check out the patch release branch.
In the git commit history, identify the commit for the fix you wish to add to the release. You can usually easily find this by looking at the original Pull Request for the (normally the PR can be found by looking through the issue coments on GitHub). You’re looking for a message in the PR about the merge, usually at the end, that looks like this:
jeenbroekstra merged commit 5d13554 into eclipse:master
The commit number (5d13554) is what you’re after.
Add this fix to the release branch by executing the following command:
git cherry-pick -m 1 5d13554
The -m 1 flag is necessary because this is a merge-commit, which has two parents: we need inform git which parent commit it needs to use as the base (we select 1, which is the master branch, to ensure that only changes introduced by this fix are included).
Once all fixes are applied to the release branch, and the build is stable (NB verify by executing mvn clean verify), we can tag and finalize the release:
Set the maven pom version numbers. We need to set the project version to from 2.1.6-SNAPSHOT to 2.1.6 by using:
This will ask for the new version number. Enter 2.1.6 to indicate that this is the actual code for 2.1.6 release. After this is done, execute
which will remove backup files. Finally, commit the changes and push:
git commit -s -a -m "patch release 2.1.6"git push
Tag the version and push the tag upstream:
git tag 2.1.6git push origin 2.1.6
Once the release is complete, the hotfix branch needs to be deleted. Although this can of course be done from the command line, it is cumbersome, and we recommend using a decent Git client (like SourceTree) that can do this for you.
Note that, although the branch is deleted, the release tag is still in place, for future use of further hotfix releases.
We use the Eclipse RDF4J Jenkins CI instance to build and deploy new releases to the Central Repository.
To do this, log in to Jenkins, and start the job named rdf4j-client-deploy-release-ossrh-central.
The job will ask for the github release tag as an input parameters, e.g. ‘2.2.1’. It will automatically start deployment jobs for the rdf4j-storage, rdf4j-tools, and rdf4j-testsuite subprojects, in the correct sequence.
These jobs will automatically check out the release tag, build the project, and upload all artifacts to OSS Sonatype.
After successful upload, it will also automatically invoke synchronization with the Central Repository.
Note that after successful completion, the artifacts may not be available on the Central Repository for several hours.
Once this completes, the SDK and onejar can be found in assembly/target.
Verify that the SDK is complete by inspecting its contents (in particular, check that javadoc is included).
Uploading the SDK and onejar
SFTP to build.eclipse.org. You will need to provide your eclipse username and password.
Go to remote directory /home/data/httpd/download.eclipse.org/rdf4j.
Upload the SDK and onejar archives to this directory (NB we currently only distribute the SDK zip file, not the tar.gz file)
Minor and Major releases
Minor and major releases require a formal release review, and because this is the case, they need to be planned well in advance, and the project lead needs to manage what can go into each release, and prepare necessary documentation (both technical and legal) for review.
A release can only be done once its review is successfully concluded. Eclipse release review are announced in regular cycles, and always complete on the first or third Wednesday of each month. For this reason, we schedule our releases to happen on a first or third Thursday.
A release review runs for a week. Although mostly a formality, it does need some careful preparation and planning. It needs to be formally applied for, and this application in turn requires that several pieces of documentation are in order:
The project’s IP log needs to be filed and approved by the Eclipse legal team;
The IP log can be automatically generated and submitted to the legal team. Obtaining approval may require several days, so it’s good practice to submit this at least two weeks before the planned release date.
Typical review documentation can be a simple reiteration of the most important new features, a link to the issue tracker/release notes and documentation, and a remark about compatibility (if applicable). Once the review documentation is up, a mail needs to be sent to firstname.lastname@example.org to ask for approval. Here’s an example of such a message, which was to get approval for the RDF4J 2.2 release:
Dear PMC members,
Can I get your approval for RDF4J release 2.2, scheduled for February 2.
Release review info: https://projects.eclipse.org/projects/technology.rdf4j/reviews/2.2-release-review
Issue tracking the release: https://bugs.eclipse.org/bugs/show_bug.cgi?id=510577
When IP log approval and review approval have been given, the review can be scheduled. To do this, email@example.com needs to be notified. This can happen through the eclipse project governance page (accessible through the project site), which will show a link at the top of the page for the planned release.
Prior to a minor release, the develop branch is merged into the master branch
(along with the develop branch’s version) to facilitate release review.
This will increment the master version to the latest major/minor SNAPSHOT version.
After the review is complete the steps to create a minor release are the same as the patch release steps.
IMPORTANT: It is important that only features and fixes that have already been scheduled
for release (via PR milestone labels) be merged into the develop branch, so
that there is no confusion as to what will be included in the next minor release.
Once a minor release is published the develop minor version should be incremented to the next SNAPSHOT
version and any approved features that are scheduled for this next minor
version should be merged into develop branch.
Optional: publishing docker images
Occasionally a docker server/workbench image could be built
and pushed to https:/hub.docker.com/eclipse/rdf4j-workbench,
which is part of the Eclipse organizational account.
Since this account is managed separately by the Eclipse Foundation,
only a limited number of committers will be granted access by the EMO.
The Dockerfiles are stored in rdf4j-tools/assembly/src/main/dist/docker,
and currently there are two supported architectures: amd64 (Intel/AMD x86-64) and arm64v8.