Release Blog Post

Release blog post

Produces the selenium-4-N-released.md post and its selenium_4.N.jpg share image for a freshly released Selenium version, following the same structure as previous posts under website_and_docs/content/blog/*/selenium-4-*-released.md.

Run every step from the repo root. Ask the user for the new version (e.g. 4.41) if it isn't already known — everything else below is derived from it.

1. Scaffold

scripts/release-updates.sh 4.41

This, for version 4.41 (previous = 4.40):

• Bumps 4.40.x → 4.41.0 (and the adjacent human-readable release date) in website_and_docs/layouts/partials/selenium-clients-and-webdriver-bindings.html and website_and_docs/layouts/downloads/list.html.
• Copies the previous release's blog post to website_and_docs/content/blog/<year-of-release>/selenium-4-41-released.md, git adds it, replaces 4.40 → 4.41 throughout, and sets date: to the selenium-4.41.0 tag's commit date (the year is derived the same way, so this works across year boundaries).
• Prints three deduped, sorted {{< gh-user ... >}} lists — Selenium, Docs, and Docker contributors — for commits between the selenium-4.40.0 and selenium-4.41.0 tags.

Everything after this point is manual editing of the new blog file using the data gathered in the remaining steps. The copied file still has the previous release's prose and contributor lists — all of it needs replacing, not just the version string.

2. Split contributors: external vs. Selenium Team

The Selenium Team roster is the set of gh-user logins already listed on website_and_docs/content/project/structure/_index.html (Project Leadership Committee plus all per-binding committers) — extract it with:

grep -oE 'api.github.com/users/[A-Za-z0-9_.\[\]-]+' website_and_docs/content/project/structure/_index.html \
  | sed 's#api.github.com/users/##' | sort -u -f

(The seleniumhq/selenium-tlc and seleniumhq/selenium-committers GitHub teams are close but incomplete for this purpose — several names on the structure page, e.g. joerg1985, nvborisenko, VietND96, aren't members of either GitHub team. Use the structure page, not the teams API.)

Also drop bot/automation accounts from all three lists before anything else — they show up in the raw commit data but were never credited in past posts: dependabot[bot], github-actions[bot], renovate[bot], selenium-ci.

For each of the three (now bot-free) contributor lists from step 1:

• Logins that appear on the structure-page roster → remove from that list, and add to one merged, deduped, alphabetically-sorted (case-insensitive) "Selenium Team Members" list instead.
• Everyone else stays under their original section (Selenium / Selenium Docs & Website / Docker Selenium).

If a contributor list ends up empty after removing team members, omit that ### section for this release rather than leaving an empty block.

3. Draft the changelog sections

Fetch the release notes for the new tag and the recent docker-selenium activity:

gh api repos/seleniumhq/selenium/releases/tags/selenium-4.41.0 --jq '.body'
gh api --method GET /repos/seleniumhq/docker-selenium/commits -f since="<SINCE_COMMIT_DATE>" -f until="<UNTIL_COMMIT_DATE>" -f per_page=1000 --jq '.[].commit.message'

(SINCE_COMMIT_DATE/UNTIL_COMMIT_DATE are the same tag commit dates step 1 already computed — rerun the two gh api repos/seleniumhq/selenium/commits/selenium-4.X.0 --jq '.commit.committer.date' calls if needed.)

Read the PR titles in the changelog body and write, in the same tone as prior posts:

• ✨ Highlights: 5-7 bullets, one per notable theme (new BiDi commands, a new class, Chrome DevTools version bump, Grid behavior changes, build/infra work). Bold the binding name in brackets when a bullet is specific to one, e.g. **[Java]** .... Check whether the changelog mentions new Chrome DevTools protocol versions and call them out first if so.
• 📦 Notable Changes: one ### subsection per binding (Java, Python, Ruby, .NET, Grid, Build & Infra) with 3-5 bullets each, paraphrasing the PR titles — don't just paste them verbatim.
• 🐳 Docker Selenium: bullet list of the docker-selenium commit messages (they already include their PR number, e.g. Docker: update X (#3002)), followed by the fixed line [See all changes](https://github.com/SeleniumHQ/docker-selenium/releases).

Skip any of the binding subsections that had no meaningful changes rather than inventing content.

4. Edit the blog file

In the scaffolded file:

• Replace the ## ✨ Highlights, ## 📦 Notable Changes, and Docker Selenium sections with the drafts from step 3.
• Replace each ### [Selenium](...), ### [Selenium Docs & Website](...), and ### [Docker Selenium](...) contributor block with the non-team logins from step 2, each as {{< gh-user "https://api.github.com/users/<login>" >}} on its own line.
• Replace the ### [Selenium Team Members][team] block with the merged team-member list from step 2.
• Double-check date: and the images: path both reflect the new version (step 1 sets these, but verify — images: should point at /images/blog/<year>/selenium_4.41.jpg).

5. Generate the release image

scripts/generate-release-image.sh 4.41 <release-date YYYY-MM-DD> website_and_docs/static/images/blog/<year>/selenium_4.41.jpg

This composites "Selenium 4.41 Released" and the Selenium logo over a gradient background, auto-picked by season from the release date (no photo needed). If the user supplies a background photo instead (matching the look of some earlier posts, e.g. a stock photo), pass it as a 4th argument:

scripts/generate-release-image.sh 4.41 <release-date> <output.jpg> /path/to/background.jpg

Read the resulting image back to sanity-check text placement and legibility before moving on — regenerate (a different --seed-driven gradient will differ slightly) if the text is hard to read against the background.

6. Review

• Reread the finished post end to end against website_and_docs/content/documentation/about/style.en.md.
• Run ./build-site.sh (or cd website_and_docs && hugo server) if practical, and check the post renders — especially the gh-user shortcodes and the image.
• Do not commit or push — leave the changes for the user to review first, per their usual workflow.