Skip to content

Release process for v6

Jump to bottom
Mahmoud Ben Hassine edited this page Jul 23, 2025 · 2 revisions

Part 1: Prepare the release

  1. In the branch to release (main for milestones, 5.0.x, 5.1.x, etc), update the main pom.xml with release versions of Spring snapshot dependencies and upgrade other dependencies if needed. Here is an example: d594be1d. Make sure dependencies versions align with those used by the Spring Boot version that will consume the current release.
  2. Run a full build with ./mvnw clean verify
  3. Commit and push the changes in pom.xml with a message like: Prepare release 5.0.5

Part 2: Stage release on Artifactory

  1. Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
  2. Run the "Artifactory Staging" workflow ❗ from the branch to release ❗and provide the version to release. This will build the artifacts, sign them with GPG and deploy them in Artifactory's libs-staging-local repository.
  3. Do a smoke test with the staged jars in http://repo.spring.io/libs-staging-local/org/springframework/batch. check the integrity of the artifacts to see if jars are not corrupted or empty, etc.

❗ Heads-up: The "Artifactory Staging" workflow is designed to be idempotent (it has no git side effects). If something is wrong with the staged release, the same workflow can be re-run with the same version and a new release will override the corrupted one on the staging repository.❗

Part 3: Promote release to Maven Central

  1. Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
  2. Run the "Maven Central Release" workflow ❗ from the main branch ❗ and provide the build name and build number of the staged release in Artifactory. This will download the artifacts from the Artifactory's staging repository and upload them to Maven Central.

Part 4: Tag the release

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 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):

$./mvnw versions:set -DgenerateBackupPoms=false -DnewVersion=5.0.5
$git commit -a -m "Release version 5.0.5"
$git tag -a v5.0.5 -m "Release version 5.0.5"
$./mvnw versions:set -DgenerateBackupPoms=false -DnewVersion=5.0.6-SNAPSHOT
$git commit -a -m "Next development version"
$git push upstream 5.0.x
$git push upstream v5.0.5

NB: The "v" prefix in the tag name is important, see https://github.com/spring-projects/spring-batch/issues/4183.

Part 5: Update the documentation

  1. Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
  2. Run the "Documentation Upload" workflow from the branch to release ❗and provide the version to release. This will generate a distribution of the documentation (java docs and XSDs) and upload it to the documentation server where needed.

The reference documentation should be automatically generated and published with the Antora-based process that is triggered automatically on every new release or tag. In case of any issue, the reference documentation can be re-generated by running the Deploy Docs action from the docs-build branch and by specifying the tag to reprocess (ex v5.1.3).

Part 6: Post release tasks

  1. Generate the release notes with the Generate Release notes action. You need to specify the milestone version (for example 5.0.5) and the version of the Github Changelog Generator (for example 0.0.8). Copy the generated content from the action's log, amend it as needed and use the result to create a release on Github. Heads-up: Add "Dependency upgrades" and "Full changelog" sections to the release notes, those are not generated by the "Github Changelog Generator" tool.
  2. Update the project's page on spring-website with the latest release/snapshot versions.
  3. Write a release announcement blog post.
  4. Tweet about the release using the @SpringBatch handle.
  5. Post a message in the #spring-release slack channel.
  6. Close the GitHub milestone of the release
  7. Update Spring dependencies to next snapshot versions in pom.xml. Here is an example: 4dda48df.
  8. Update the "Latest news" section in the main README.md with the link to the release announcement's blog post.
Clone this wiki locally