-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Release process for v5
- Part 1: Pre-release tasks
- Part 2: Release milestones to Artifactory
- Part 2.1: Deploy the milestone to Artifactory
- Part 2.2: Test the deployed milestone release
- Part 3: Release GAs to Maven Central
- Part 3.1: Stage the release on Artifactory
- Part 3.2: Test the staged release
- Part 3.3: Promote the release to Maven Central
- Part 4: Post-release tasks
- Part 4.1: Create git tag
- Part 4.2: Update documentation
- Part 4.3: Announce the release
- Part 5: Rolling back a release
- Part 5.1: Rolling back a milestone release
- Part 5.2: Rolling back a GA release
- Get the latest changes from the upstream repository of the branch being released.
- Check if
pom.xml
refers to any snapshot/milestone dependencies. Later in the release process, the enforcer plugin will check for snapshots, but not for milestones. So it is better to do the verification at this point.
❗ This section is for milestone releases only ❗
- Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
- Run the "Artifactory Milestone Release" workflow by providing the milestone version to release. This will deploy the milestone release to https://repo.spring.io/libs-milestone-local/org/springframework/batch
Check uploaded jars in http://repo.spring.io/libs-milestone-local/org/springframework/batch and do a smoke test with the deployed milestone version: check the integrity of the artifacts to see if jars are not corrupted or empty, etc.
Note: The process ends here for milestone releases
- Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
- Run the "Artifactory Staging" workflow by providing the version to release.
Check uploaded jars in http://repo.spring.io/libs-staging-local/org/springframework/batch and do a smoke test with the staged release: check the integrity of the artifacts to see if jars are not corrupted or empty, etc.
- Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
- Run the "Maven Central Release" workflow by providing the version to release. This will download the artifacts from the Artifactory staging repository, GPG sign them and upload them to Maven Central.
None of the previous Github Actions changes the version in the code and pushes the changes to the upstream repository. The version change is done manually on purpose. At this point, the release should have been staged, tested and promoted to Artifactory and Maven Central. It is now safe to change the version in the code and push it to the upstream repository. From the root directory of the project, run the following commands (change the version number accordingly, no need to create a variable, substitute it, etc):
$./mvnw versions:set -DgenerateBackupPoms=false -DnewVersion=5.0.2
$git commit -a -m "Release version 5.0.2"
$git tag -a v5.0.2 -m "Release version 5.0.2"
$./mvnw versions:set -DgenerateBackupPoms=false -DnewVersion=5.0.3-SNAPSHOT
$git commit -a -m "Next development version"
$git push upstream main
$git push upstream v5.0.2
NB: The "v" prefix in the tag name is important, see https://github.com/spring-projects/spring-batch/issues/4183.
- Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
- Run the "Documentation Upload" workflow by providing the version to release. This will generate a distribution of the documentation (java docs, reference docs, etc) and upload it to the documentation server where needed.
- Generate the release notes and create a release on Github.
- Update the project's page on Contentful with the latest release/snapshot versions.
- Write a release announcement blog post.
- Tweet about the release using the
@SpringBatch
handle. - Post a message in the
#spring-release
slack channel.
The "Artifactory Milestone Release" workflow is designed to be idempotent (it has no git side effects). If something is wrong when testing the milestone release in step 2.2, the same workflow can be re-run with the same version and a new milestone will override the corrupted one.
If something goes wrong while testing staged artifacts in step 3.2, the workflow "Artifactory Staging" can be re-run with the same version and a new release will override the corrupted one.