Ensure you have no changes in your local repository. Change to a new branch. For example:
$ git checkout -b 5.5.0-RC1-dependencies
Review the rules in build.gradle to ensure the rules make sense. For example, we should not allow major version updates in a patch release. Also ensure that all of the exclusions still make sense.
The following Gradle command will update your dependencies creating a commit for each dependency update. The first invocation of the command will take quite a while (~20 minutes depending on internet speed) to run because it is indexing all the versions of all the dependencies.
$ ./gradlew updateDependencies
Review the commits to ensure that the updated dependency versions make sense for this release. For example, we should not perform a major version update for a patch release.
$ git log
If any of the versions don’t make sense, update build.gradle
to ensure that the version is excluded.
Run all the checks:
$ ./gradlew check
If they don’t work, you can run a git bisect to discover what broke the build. Fix any commits that broke the build.
Check out the original brach:
$ git checkout -
The following command will update the dependencies again but this time creating a ticket for each update and placing Closes gh-<number>
in the commit. Replacing the following values:
<github-personal-access-token> - Replace with a GitHub personal access token that has a scope of public_repo
<next-version> - Replace with the title of the milestone you are releasing now (i.e. 5.5.0-RC1)
$ ./gradlew updateDependencies -PupdateMode=GITHUB_ISSUE -PgitHubAccessToken=<github-personal-access-token> -PnextVersion=<next-version>
Apply any fixes from your previous branch that were necessary.
The following command will check if there are any open issues for the ticket. Before running the command, replace the following values:
<github-personal-access-token> - Replace with a GitHub personal access token that has a scope of public_repo
. This is optional since you are unlikely to reach the rate limit for such a simple check.
<next-version> - Replace with the title of the milestone you are releasing now (i.e. 5.5.0-RC1)
$ ./gradlew gitHubCheckMilestoneHasNoOpenIssues -PgitHubAccessToken=<github-personal-access-token> -PnextVersion=<next-version>
Alternatively, you can manually check using https://github.com/spring-projects/spring-security/milestones
Update the version number in gradle.properties
for the release, for example 5.5.0-M1
, 5.5.0-RC1
, 5.5.0
You will need to update the antora.yml version. If you are unsure of what the values should be, the following task will instruct you what the expected values are:
./gradlew :spring-security-docs:antoraCheckVersion
Run the build using
$ ./gradlew check
Push the commit and GitHub actions will build and deploy the artifacts If you are pushing to Maven Central, then you can get notified when it’s uploaded by running the following:
$ ./scripts/release/wait-for-done.sh 5.5.0
Announce via Slack on
#spring-release,
including the keyword spring-security-announcing
in the message.
Something like:
spring-security-announcing 5.5.0 is available.
Tag the release and then push the tag
git tag 5.4.0-RC1 git push origin 5.4.0-RC1
Update gradle.properties
version to next SNAPSHOT
version, update antora.yml, and then push
The following command will update https://spring.io/projects/spring-security#learn with the new release version using the following parameters
<github-personal-access-token> - Replace with a GitHub personal access token that has a scope of public_repo
<next-version> - Replace with the milestone you are releasing now (i.e. 5.5.0-RC1)
<previous-version> - Replace with the previous release which will be removed from the listed versions (i.e. 5.5.0-M3)
$ ./gradlew saganCreateRelease saganDeleteRelease -PgitHubAccessToken=<github-personal-access-token> -PnextVersion=<next-version> -PpreviousVersion=<previous-version>
Generate the Release Notes replacing:
<next-version> - Replace with the milestone you are releasing now (i.e. 5.5.0-RC1)
$ ./gradlew generateChangelog -PnextVersion=<next-version>
Copy the release notes to your clipboard (your mileage may vary with the following command)
cat build/changelog/release-notes.md | xclip -selection clipboard
Create the release on GitHub, associate it with the tag, and paste the generated notes
In GitHub Milestones, create a new milestone for the next release version
Move any open issues from the existing milestone you just released to the new milestone
Close the milestone for the release.
Create a Blog
Tweet from [@SpringSecurity](https://twitter.com/springsecurity)
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。