While Selenium code is tied to Chrome versions, the goal is to release a minor version of Selenium between Early Stable and Stable release dates as specified in Chromium Release Schedule. Make sure the release you are targeting has been announced on the Release Blog.

• Communicate in Selenium Chat a reminder of the upcoming release
• Blockers should be tracked in the applicable Release Milestone
• Check Pull Requests for anything that needs to be added to the milestone
• Check Renovate Dashboard for anything that should be updated before release
• Ensure CI is passing, both RBE and CI; note that the Scheduled CI are the only ones guaranteed to have everything run.

Run the Release Preparation workflow with the target tag and Chrome channel.

Use selenium-X.Y.0 for a full release. Use selenium-X.Y.Z-language for a patch release.

This workflow:

• Locks trunk for the duration of the release process
• Updates versions, dependencies, lockfiles, and changelogs for the requested release
• For full releases, updates CDP, pinned browsers, Selenium Manager, multitool binaries, Authors, and Rust changelogs
• Creates Release Preparation PR with all changes
• If this workflow fails, trunk will unlock and a message sent to the selenium-tlc Slack channel

When all tests have passed, a member of the selenium-tlc team needs to use the GitHub UI option to bypass the release ruleset and merge the release preparation PR. GitHub will recognize the PR has been merged and automatically start the release workflow. The merge commit is the commit that gets tagged and released.

Merging the release preparation PR starts the Release Selenium workflow.

This workflow:

• Tags the release
• Publishes packages for the released bindings
• Publishes the GitHub Release and release assets when applicable
• Updates API docs for the released bindings
• Verifies published packages
• Unlocks trunk if everything is successful
• Bumps binding versions to nightly and publishes nightly packages
• Updates the release mirror for full releases
• If this workflow fails, trunk will remain locked and a message sent to the selenium-tlc Slack channel with failure details

The most common failure in our release has been one binding not publishing. Previously this has resulted in needing to do a bunch of things manually. The publish step, except for Java should be idempotent now. If Java failed to run, any rerun of the job will result in a failure by design.

So if one publish step fails, do that locally, then then select "rerun failed jobs" in GitHub (not rerun all jobs). See the manual prerequisite steps below to ensure your system is set up for all commands.

You can see what has been successfully published (but Java is complicated):

./go all:verify
# or, for a patch release:
./go <language>:verify

Address any errors and rerun the unsuccessful release locally with ./go <language>:release

If the "rerun failing jobs" option is unsuccessful and a publish step has failed, the following must still be done:

1. Publish unsuccessful bindings locally using: ./go <language>:release
2. Generate Java and .NET packages with: ./go java:package && ./go dotnet:package
3. Copy the files in selenium/build/dist/ to the Draft GitHub Release
4. Verify and Publish the GitHub Release
5. Double check ./go all:verify
6. Run the Update Documentation workflow - select "all" for full releases
7. Run the Unlock Trunk workflow before additional commits can be made to trunk.
8. Bump binding versions to nightly, and run updates to synchronize lockfiles and commit:

   ./go all:version nightly && ./go rust:version nightly
   ./go all:update && ./go rust:update
   git commit -am "[build] Reset versions to nightly after <tag> release"
   git push

9. Run nightly-release workflow so the nightly code isn't behind the released code
10. Run the mirror-selenium-releases workflow.

Prefer the automated release, but if you need to release all or part of Selenium locally, make sure you are on the commit from the merged release preparation PR before running any release commands.

1. Setup a Sonatype Central account
2. Generate a User Token; store username and password in MAVEN_USER and MAVEN_PASSWORD, or configure ~/.m2/settings.xml with a central server.
3. Install GnuPG, generate a key and distribute it. See Maven's GPG Instructions.

Be registered as an owner on NuGet, then set NUGET_API_KEY.

Be registered as a gem owner on RubyGems, then set GEM_HOST_API_KEY or configure ~/.gem/credentials.

Be registered as an Owner/Maintainer on PyPI, then set TWINE_PASSWORD or configure .pypirc.

Be registered as an Owner/Maintainer on npmjs, then configure ~/.npmrc with an npm auth token.

The local equivalent to running the Release Preparation workflow is to run:

./go release_updates <tag> <channel>

For the tag, use selenium-X.Y.0 for a full release and selenium-X.Y.Z-language for a patch release. the release_updates task does not actually do the tagging, so also run:

git tag <tag>
git push origin <tab>

The previous step has set the versions and the tag so all that is needed to publish is ./go all:release or: ./go <language>:release.

The Java release task uploads to the Central Portal OSSRH-compatible API and requests automatic publishing. Check https://central.sonatype.com/publishing/deployments for status if the release task times out or returns an error.

Verify everything is correct with ./go all:verify or ./go <language>:verify

We only publish new GitHub Releases for minor version bumps, but if Java or .NET have patch version releases, add the binaries using step 3 below.

1. In GitHub UI set title, tag, target commit, generate release notes with previous minor tag
2. Paste the contents of selenium/scripts/github-actions/release_header.md at the top of the notes (above the generated list).
3. Copy the java and .NET binaries that were generated in the publish step from: /selenium/build/dist/ into the assets section.
4. Publish

1. Bump the versions to nightly with ./go all:version nightly or ./go <language>:version nightly
2. Run ./go all:update or ./go <language>:update to fix lockfiles
3. Run ./go rust:version nightly && ./go rust:update if it is a minor version
4. Commit and push the nightly version and dependency updates
5. Run nightly-release workflow so the nightly code isn't behind the released code
6. Run the mirror-selenium-releases workflow.

1. Run ./go all:docs or ./go <language>:docs which generates documentation and puts them in build/docs/api/
2. Checkout gh-pages branch
3. Copy files from build/docs/api/ to docs/api

• Update versions and dates in Documentation repo for examples and in selenium-clients-and-webdriver-bindings.html
• Announce in blog post and/or social media as necessary