Skip to content

Release Process

BJ Hargrave edited this page Mar 15, 2022 · 3 revisions

Release Process

This is a description of the release process. This process can currently be executed by the project leader:

  • BJ Hargrave (project leader) @bjhargrave

Credentials

  • OSS Nexus Sonatype – The necessary credentials are provisioned as GitHub Secrets in the GitHub repository.

Binary Repos

The binary repositories are hosted on OSSRH. We use the Maven groupId org.eclipse.transformer.

Repository Description
released Released artifacts
staging Staged release artifacts
snapshot Snapshot artifacts

Github Repository

All code is stored on GitHub in https://github.com/eclipse/transformer. The normal development takes place on the main branch. Changes are merged via PRs. PRs are automatically built with Github Actions for verification but do not release binaries. A commit on main is automatically released to snapshot for any successful build. A commit on the release branch is also released to the staging repository for a release candidate. Once the staging repo is closed and released, the release artifacts will be available from released.

Summary

This process describes the steps to go from V1 to V2, where V1 and V2 are valid versions with a MAJOR.MINOR.MICRO (no qualifier). For example, V1 could be 1.1.0. This release process is not an atomic process, it can take a few weeks. During these weeks, a number of release candidates (RCx) are provided for the users to test against.

First, the main and release branch are prepared for a release cycle. The main branch is moved from V1-SNAPSHOT to V2-SNAPSHOT while the release branch still uses the version V1-SNAPSHOT. The branches are properly tagged and built, this is detailed later in a checklist. Their build output will go to snapshot but main will now build a new snapshot version V2-SNAPSHOT and release will build the V1-SNAPSHOT.

During this period fixes are being made on main. If these fixes are deemed crucial enough to include in the current release cycle then they are cherry picked on release. In principle, about once every other week a new release candidate is made available for the end users.

Every new RC is properly tagged in git repo from the release branch with V1-RC1, V1-RC2, etc.

At the big day when the last RCx has been approved, the release branch is adjusted to not generate a snapshot but an actual release without the SNAPSHOT qualifier. The branch is adjusted to generate V1, tagged and pushed. With the GitHub actions workflow, this will build the release branch and deploy to staging. After this release is approved, the releaser will closed and release the staging which will publish the release artifacts to released (Maven Central).

Preparation of First Release Candidate

Make sure main is fully committed and it builds properly.

git checkout main
git pull

Set release branch to state of main branch.

git branch --force release main
  • In org.eclipse.transformer.parent/pom.xml change <revision>V1-SNAPSHOT</revision> to <revision>V2-SNAPSHOT</revision>.

Build main and push:

git add .
git commit -m "build: Start V2 stream"
./mvnw clean install
git push origin main

Prepare the release branch.

git checkout release
git tag -s V1-RC1
git push --force origin release V1-RC1
  • Verify that that the Wiki release notes are updated.

RC2...

  • When there are changes on main that should be incorporated on the next release candidate they should be cherry picked onto release.
git checkout release
git cherry-pick ...
git tag -s V1-RCx
git push origin release V1-RCx
  • Verify that that the Wiki release notes are updated.

Release

git checkout release
  • Remove -SNAPSHOT from <revision>V1-SNAPSHOT</revision> in org.eclipse.transformer.parent/pom.xml.
git add .
git commit -m "Release V1"
git tag -s V1
git push origin release V1

After the push, the release will be built and released into the staging repository.

  • The releaser must then review the staging to ensure the release is as expected. If ok, then the releaser must close and release the staging repository to complete the release process.

  • Go to https://github.com/eclipse/transformer/releases/tag/V1 and create a GitHub Release for the V1 tag. Set the release title to:

    Eclipse Transformer V1

    and set the description to include a link the the release wiki page

    See [Release Notes](https://github.com/eclipse/transformer/wiki/Release-Notes-V1).