Skip to content

Releasing Artifacts

Jump to bottom
Christian Kaltepoth edited this page May 19, 2021 · 15 revisions

Release Artifacts

This section describes how to release Eclipse Krazo artifacts to Maven Central.

Notes

  • A few steps are currently performed manually (like updating versions in pom.xml and creating tags). We may automate these steps later on to further simplify the process.
  • Some steps in the release process require performing operations on staging repositories on the Sonatype OSSRH Nexus instance. You can either request access permissions for the corresponding group via the corresponding JIRA issue or use the existing "remote control" build jobs to perform these operations via Jenkins.

Preparing the release

First define three environment variables. This will allow you to copy & paste the following commands:

export BASE_BRANCH="master"
export RELEASE_VERSION="1.0.0-Beta1"
export DEVELOP_VERSION="1.0.0-SNAPSHOT"

The release should be performed on a separate branch:

git checkout -b jenkins-release ${BASE_BRANCH}

Now update the relevant versions in the pom.xml:

mvn versions:set -DgenerateBackupPoms=false -DnewVersion=${RELEASE_VERSION}

Now verify that everything is fine:

  • Use git diff to check that all version were updated
  • Use grep to look if there are any SNAPSHOT dependencies left
  • Verify that spec.version is set correctly in the parent pom.
  • Maybe more?

Then commit the changes and tag the result:

git commit -am "Preparing ${RELEASE_VERSION} release"
git tag -a -m "${RELEASE_VERSION}" ${RELEASE_VERSION}

The next step is to update the version for the next development iteration:

mvn versions:set -DgenerateBackupPoms=false -DnewVersion=${DEVELOP_VERSION}
git commit -am "Preparing for next development iteration"

Then push the release branch to the upstream repository:

git push upstream jenkins-release --follow-tags

Now proceed with the next section.

Running the release job

Now open our Jenkins instance.

In the first step you should check that there is no existing staging repository on Nexus. You can do this by running the staging-list and inspecting the output or by manually logging into the OSSRH Nexus server.

Now run the release job. The job expects the git tag to release as the only parameter. The job will checkout the corresponding tag, build the artifacts, sign them and upload them to a new Nexus staging repository.

If the job was successful, you should close the newly created staging repository. First run staging-list again to obtain the repository id. Then run staging-close and provide the repository id for the REPO_ID parameter. If you have a OSSRH account, you can also do this via the UI.

Now you can check the staging repository contents:

https://jakarta.oss.sonatype.org/content/repositories/${REPO_ID}

If you are performing real major/minor release and not a patch/RC/beta release, you must now first the release review before continuing with the next step.

To release the staging repository to Maven Central, start the staging-release job and provide the repository ID as a parameter as already done for the close operation. The job will release the repository to Maven Central AND automatically drop it after that.

If anything goes wrong, you can drop the current staging repository using the staging-drop job and start over.

Final steps

The last step is to merge the jenkins-release branch into the base branch. Because we are using a protected branch, this can only be done via a pull request. So just create a pull request to integrate the jenkins-release branch into the corresponding branch.

Other things worth checking:

  • Close/Update corresponding milestone on GitHub
  • Update project page version metadata available here
Clone this wiki locally