Spring/spring-batch
Spring/spring-batch
1
0
Fork 0
mirror of https://github.com/spring-projects/spring-batch.git synced 2024-07-14 23:56:54 +08:00
Code Issues Packages Projects Releases Wiki Activity

Updated Release process for v5 (markdown)

Mahmoud Ben Hassine 2023-12-13 14:34:45 +01:00
parent 53a726bd9b
commit 6fd90dfba9
1 changed files with 53 additions and 82 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

135
Release-process-for-v5.md

@ -1,103 +1,75 @@
# Overview of the release process:
❗ Heads-up: The release process is different between milestones and GAs, so execute **only** the process that corresponds to the type of the release you are about to publish❗
* Part 1: Prepare the release
* Part 2: Perform the release
* Part 2.1: Release milestones to Artifactory
* Part 2.1.1: Deploy the milestone to Artifactory
* Part 2.1.2: Test the deployed milestone release
* Part 2.2: Release GAs to Maven Central
* Part 2.2.1: Stage the release on Artifactory
* Part 2.2.2: Test the staged release
* Part 2.2.3: Promote the release to Maven Central
* Part 3: Tag the release
* Part 4: Update the documentation
* Part 5: Post-release tasks
# Release GAs to Maven Central
# Part 1: Prepare the release
### Part 1: Prepare the release
1. Update the main `pom.xml` with milestone/release versions of Spring snapshot dependencies and upgrade other dependencies if needed. Here is an example: [d594be1d](https://github.com/spring-projects/spring-batch/commit/d594be1d8725c07e5c9d7f8a54bf2a6040ba71d9). Make sure dependencies versions align with [those](https://github.com/spring-projects/spring-boot/blob/3.0.x/spring-boot-project/spring-boot-dependencies/build.gradle) used by the Spring Boot version that will consume the current release.
2. Run a full build with `./mvnw clean verify site`
3. Commit and push the changes in `pom.xml` with a message like: `Prepare release 5.0.2`
1.1 In the branch to release (`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](https://github.com/spring-projects/spring-batch/commit/d594be1d8725c07e5c9d7f8a54bf2a6040ba71d9). Make sure dependencies versions align with [those](https://github.com/spring-projects/spring-boot/blob/3.0.x/spring-boot-project/spring-boot-dependencies/build.gradle) used by the Spring Boot version that will consume the current release.
1.2 Run a full build with `./mvnw clean verify`
1.3 Commit and push the changes in `pom.xml` with a message like: `Prepare release 5.0.5`
# Part 2: Perform the release
### Part 2: Stage release on Artifactory
❗ Heads-up: The release process is slightly different between milestones and GAs, so execute **only** the part of the process that corresponds to the type of the release you are about to publish (ie part 2.1 or part 2.2, but not both) ❗
2.1 Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
## Part 2.1: Release milestones to Artifactory
2.2 Run the "Artifactory Staging" workflow **from the branch to release** ❗and provide the version to release.
### Part 2.1.1: Deploy the milestone release to Artifactory
2.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
3.1 Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
3.2 Run the "Maven Central Release" workflow **from the branch to release** ❗ and provide the version to release. This will download the artifacts from the Artifactory staging repository, sign them with GPG 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.
# Release Milestones to Artifactory
### Part 1: Deploy the milestone release to Artifactory
1. Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
2. 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
### Part 2.1.2: Test the deployed milestone release
### Part 2: Test the deployed milestone release
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.
#### Test within an IDE
* Download the [release test project](https://raw.githubusercontent.com/wiki/spring-projects/spring-batch/projects/spring-batch-release-test.zip) and unzip it
* Open it in your IDE and update the release version to test + comment the spring-staging repository
* Run the `MyBatchJobConfiguration` class and then the `MyBatchJobTests` suite
#### Test on the CLI
```
$>wget https://raw.githubusercontent.com/wiki/spring-projects/spring-batch/projects/spring-batch-release-test.zip
$>unzip spring-batch-release-test.zip && cd spring-batch-release-test
$>vim pom.xml # update the release version to test and comment the spring-staging repository
$>mvn exec:java -Dexec.mainClass=MyBatchJobConfiguration # make sure the job is executed correctly
$>mvn test # make sure the tests pass (no functional tests here, we are only checking the integrity of `spring-batch-test.jar`)
```
❗ Heads-up: The "Artifactory Milestone Release" workflow is designed to be idempotent (it has no git side effects). If something is wrong with the milestone release, the same workflow can be re-run with the same version and a new milestone will override the corrupted one on the milestone repository. ❗
## Part 2.2: Release GAs to Maven Central
### Part 2.2.1: Stage the release on Artifactory
1. Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
2. Run the "Artifactory Staging" workflow by providing the version to release.
### Part 2.2.2: Test the staged 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.
##### Test within an IDE
* Download the [release test project](https://raw.githubusercontent.com/wiki/spring-projects/spring-batch/projects/spring-batch-release-test.zip) and unzip it
* Open it in your IDE and update the release version to test + comment the spring-milestones repository
* Run the `MyBatchJobConfiguration` class and then the `MyBatchJobTests` suite
#### Test on the CLI
```
$>wget https://raw.githubusercontent.com/wiki/spring-projects/spring-batch/projects/spring-batch-release-test.zip
$>unzip spring-batch-release-test.zip && cd spring-batch-release-test
$>vim pom.xml # update the release version to test and comment the spring-milestones repository
$>mvn exec:java -Dexec.mainClass=MyBatchJobConfiguration # make sure the job is executed correctly
$>mvn test # make sure the tests pass (no functional tests here, we are only checking the integrity of `spring-batch-test.jar`)
```
❗ Heads-up: The "Artifactory Staging" workflow is designed to be idempotent (it has no git side effects). If something is wrong with staged artifacts, the workflow "Artifactory Staging" can be re-run with the same version and a new release will override the corrupted one on the staging repository. ❗
### Part 2.2.3: Promote the release to Maven Central
1. Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
2. Run the "Maven Central Release" workflow by providing the version to release. This will download the artifacts from the Artifactory staging repository, sign them with GPG and upload them to Maven Central.
# Part 3: 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 Artifactory or 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):
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. 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.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
$./mvnw versions:set -DgenerateBackupPoms=false -DnewVersion=5.2.0-M1
$git commit -a -m "Release version 5.2.0-M1"
$git tag -a v5.2.0-M1 -m "Release version 5.2.0-M1"
$./mvnw versions:set -DgenerateBackupPoms=false -DnewVersion=5.2.0-SNAPSHOT
$git commit -a -m "Next development version"
$git push upstream main
$git push upstream v5.0.2
$git push upstream v5.2.0-M1
```
NB: The "v" prefix in the tag name is important, see https://github.com/spring-projects/spring-batch/issues/4183.
@ -105,16 +77,15 @@ NB: The "v" prefix in the tag name is important, see https://github.com/spring-p
# Part 4: Update the documentation
1. Go to Github Actions: https://github.com/spring-projects/spring-batch/actions.
2. Run the "Documentation Upload" workflow by providing 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.
2. Run the "Documentation Upload" workflow from the `main` branch and provide the milestone version to release. This will generate a distribution of the documentation (java docs and XSDs) and upload it to the documentation server where needed.
# Part 5: Post-release tasks
# Post release tasks
1. Generate the release notes with the [Generate Release notes](https://github.com/spring-projects/spring-batch/actions/workflows/release-notes-generation.yml) action. You need to specify the milestone version (for example `5.0.1`) and the version of the [Github Changelog Generator](https://github.com/spring-io/github-changelog-generator/releases) (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](https://github.com/spring-projects/spring-batch/releases). **Heads-up:** Add "Dependency upgrades" and "Full changelog" sections to the release notes, those are not generated by the "Github Changelog Generator" tool.
1. Generate the release notes with the [Generate Release notes](https://github.com/spring-projects/spring-batch/actions/workflows/release-notes-generation.yml) action. You need to specify the milestone version (for example `5.0.5`) and the version of the [Github Changelog Generator](https://github.com/spring-io/github-changelog-generator/releases) (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](https://github.com/spring-projects/spring-batch/releases). **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 Contentful 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. For GAs, clean up the staging repository
7. Close the [GitHub milestone](https://github.com/spring-projects/spring-batch/milestones) of the release
8. Update Spring dependencies to next snapshot versions in `pom.xml`. Here is an example: [4dda48df](https://github.com/spring-projects/spring-batch/commit/4dda48dfccf54681260f71c51f87a8c5af451d35)