From 5b500d60d7bfda209a45f0c52a8b7a387397b095 Mon Sep 17 00:00:00 2001 From: AutomatedTester Date: Fri, 6 Mar 2026 09:57:56 +0000 Subject: [PATCH 1/3] Blog about chrome moving to forthnightly releases --- website_and_docs/content/blog/2026/_index.md | 5 ++ .../blog/2026/chrome_fornightly_releases.md | 87 +++++++++++++++++++ 2 files changed, 92 insertions(+) create mode 100644 website_and_docs/content/blog/2026/_index.md create mode 100644 website_and_docs/content/blog/2026/chrome_fornightly_releases.md diff --git a/website_and_docs/content/blog/2026/_index.md b/website_and_docs/content/blog/2026/_index.md new file mode 100644 index 00000000000..91e8e83e34a --- /dev/null +++ b/website_and_docs/content/blog/2026/_index.md @@ -0,0 +1,5 @@ +--- +title: "Blog Posts - 2026" +linkTitle: "2026" +weight: 86 +--- diff --git a/website_and_docs/content/blog/2026/chrome_fornightly_releases.md b/website_and_docs/content/blog/2026/chrome_fornightly_releases.md new file mode 100644 index 00000000000..cbec711d173 --- /dev/null +++ b/website_and_docs/content/blog/2026/chrome_fornightly_releases.md @@ -0,0 +1,87 @@ +--- +title: "The Fortnightly Flutter: Why Chrome’s New Cadence is a 'Non-Event' for Selenium Users" +linkTitle: "Chrome Moves to fortnightly releases" +date: 2026-03-10 +tags: ["selenium"] +categories: ["general"] +author: David Burns [@automatedtester](https://www.linkedin.com/in/theautomatedtester//) +description: > + This blog post discusses the rationale behind the breaking change in Java BiDi implementation and the changes users will have to make. +--- + + +If you’ve been following the Chromium blog, you’ll have seen the news: Chrome is moving to a fortnightly (two-week) release cycle. Starting in September 2026, the pace of the web is effectively doubling. For the uninitiated, this sounds like a recipe for "Broken Test Friday." In the old days of manual driver management, a faster release cadence meant more frequent SessionNotCreatedException errors and more time spent hunting for the right chromedriver binary to match your updated browser. + +But I’m here to tell you: Don’t panic. If you are using a modern version of Selenium (v4.11 or newer), this change is effectively a "non-event." Thanks to Selenium Manager, the days of manually synchronizing your browser and driver are over. + +## The Problem: The Versioning Treadmill +Historically, automation engineers were stuck in a reactive loop. Chrome would auto-update in the background, your tests would fail because the driver on your PATH was stale, and you'd spend your morning manually downloading a .zip file. + +As the release cycle moves to every two weeks, the "manual" cost of maintenance becomes unsustainable. You shouldn't be a "Binary Manager"; you should be a Test Engineer. + +## The Solution: Selenium Manager & Chrome for Testing (CfT) +A few years ago, the Selenium project introduced Selenium Manager, a tool bundled with every Selenium release. It works in tandem with Google’s Chrome for Testing (CfT)—a dedicated flavor of Chrome specifically for automation that doesn't "stealth update" and has its own versioned endpoints. + +When your code starts a session, Selenium Manager silently handles the heavy lifting: + +Detection: It checks which version of Chrome is currently on your machine. + +Resolution: It discovers the matching ChromeDriver version via the CfT endpoints. + +Acquisition: If Chrome isn't found (or you need a specific version), it downloads the correct Chrome for Testing binary and the driver for you. + +Caching: It stores these in `~/.cache/selenium` so you aren't re-downloading them every time. + +## What this looks like in practice +You don't need to change your code to handle the fortnightly updates. If you have a standard setup, it just works. Here is how it looks across the bindings: + +Java +{{< tabpane langEqualsHeader=true >}} +{{< tab header="Java" >}} +// No System.setProperty needed for chromedriver +WebDriver driver = new ChromeDriver(); +// Selenium Manager automatically resolves the driver & browser behind the scenes. +{{< /tab >}} +{{< /tabpane >}} + + +Python +{{< tabpane langEqualsHeader=true >}} +{{< tab header="Python" >}} +from selenium import webdriver + +# No executable_path required + +driver = webdriver.Chrome() + +# Even if Chrome updates every two weeks, Selenium Manager fetches the right bits +{{< /tab >}} +{{< /tabpane >}} + + +Taking Control of Versions +While Selenium Manager handles the "latest" version by default, the move to a fortnightly cycle might make you want to pin your versions to ensure stability across your CI/CD pipelines. You can do this easily through ChromeOptions: + +{{< tabpane langEqualsHeader=true >}} +{{< tab header="Python" >}} +from selenium import webdriver +from selenium.webdriver.chrome.options import Options + +options = Options() + +# Pin to a specific fortnightly release + +options.browser_version = "153" + +driver = webdriver.Chrome(options=options) +{{< /tab >}} +{{< /tabpane >}} + +In this scenario, Selenium Manager will see you want version 153, find the correct CfT binary, download it, and run your tests against that specific version—regardless of what the "regular" Chrome on your machine is doing. + +The Bottom Line +The web is moving faster, and browser vendors are shipping features and security patches at an incredible rate. Our goal at Selenium is to ensure that the infrastructure of your tests remains invisible. + +The move to a two-week cycle is a testament to how far web engineering has come. With Selenium Manager, you can enjoy the benefits of a modern browser without the headache of manual maintenance. + +Keep your tests green and your drivers automated. From b116318b14a7ead9df8692f6e3cf76702668a48d Mon Sep 17 00:00:00 2001 From: AutomatedTester Date: Sat, 7 Mar 2026 11:29:41 +0000 Subject: [PATCH 2/3] Fixed description --- .../content/blog/2026/chrome_fornightly_releases.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/website_and_docs/content/blog/2026/chrome_fornightly_releases.md b/website_and_docs/content/blog/2026/chrome_fornightly_releases.md index cbec711d173..1f5358a00a9 100644 --- a/website_and_docs/content/blog/2026/chrome_fornightly_releases.md +++ b/website_and_docs/content/blog/2026/chrome_fornightly_releases.md @@ -6,7 +6,7 @@ tags: ["selenium"] categories: ["general"] author: David Burns [@automatedtester](https://www.linkedin.com/in/theautomatedtester//) description: > - This blog post discusses the rationale behind the breaking change in Java BiDi implementation and the changes users will have to make. + This blog post discusses the move of Chrome going to do a 14 day release cycle and how it's mostly a non-event for Selenium users. --- @@ -15,11 +15,13 @@ If you’ve been following the Chromium blog, you’ll have seen the news: Chrom But I’m here to tell you: Don’t panic. If you are using a modern version of Selenium (v4.11 or newer), this change is effectively a "non-event." Thanks to Selenium Manager, the days of manually synchronizing your browser and driver are over. ## The Problem: The Versioning Treadmill + Historically, automation engineers were stuck in a reactive loop. Chrome would auto-update in the background, your tests would fail because the driver on your PATH was stale, and you'd spend your morning manually downloading a .zip file. As the release cycle moves to every two weeks, the "manual" cost of maintenance becomes unsustainable. You shouldn't be a "Binary Manager"; you should be a Test Engineer. ## The Solution: Selenium Manager & Chrome for Testing (CfT) + A few years ago, the Selenium project introduced Selenium Manager, a tool bundled with every Selenium release. It works in tandem with Google’s Chrome for Testing (CfT)—a dedicated flavor of Chrome specifically for automation that doesn't "stealth update" and has its own versioned endpoints. When your code starts a session, Selenium Manager silently handles the heavy lifting: @@ -33,6 +35,7 @@ Acquisition: If Chrome isn't found (or you need a specific version), it download Caching: It stores these in `~/.cache/selenium` so you aren't re-downloading them every time. ## What this looks like in practice + You don't need to change your code to handle the fortnightly updates. If you have a standard setup, it just works. Here is how it looks across the bindings: Java @@ -44,7 +47,6 @@ WebDriver driver = new ChromeDriver(); {{< /tab >}} {{< /tabpane >}} - Python {{< tabpane langEqualsHeader=true >}} {{< tab header="Python" >}} @@ -55,10 +57,10 @@ from selenium import webdriver driver = webdriver.Chrome() # Even if Chrome updates every two weeks, Selenium Manager fetches the right bits + {{< /tab >}} {{< /tabpane >}} - Taking Control of Versions While Selenium Manager handles the "latest" version by default, the move to a fortnightly cycle might make you want to pin your versions to ensure stability across your CI/CD pipelines. You can do this easily through ChromeOptions: From 4a0f428859c52b27a1b455785db909e44905f29c Mon Sep 17 00:00:00 2001 From: AutomatedTester Date: Wed, 11 Mar 2026 13:55:52 +0000 Subject: [PATCH 3/3] update from comments --- .../blog/2026/chrome_fornightly_releases.md | 54 +++---------------- 1 file changed, 6 insertions(+), 48 deletions(-) diff --git a/website_and_docs/content/blog/2026/chrome_fornightly_releases.md b/website_and_docs/content/blog/2026/chrome_fornightly_releases.md index 1f5358a00a9..59ea5e27244 100644 --- a/website_and_docs/content/blog/2026/chrome_fornightly_releases.md +++ b/website_and_docs/content/blog/2026/chrome_fornightly_releases.md @@ -1,6 +1,6 @@ --- -title: "The Fortnightly Flutter: Why Chrome’s New Cadence is a 'Non-Event' for Selenium Users" -linkTitle: "Chrome Moves to fortnightly releases" +title: "The two-week Flutter: Why Chrome’s New Cadence is a 'Non-Event' for Selenium Users" +linkTitle: "Chrome Moves to two-week releases" date: 2026-03-10 tags: ["selenium"] categories: ["general"] @@ -10,7 +10,7 @@ description: > --- -If you’ve been following the Chromium blog, you’ll have seen the news: Chrome is moving to a fortnightly (two-week) release cycle. Starting in September 2026, the pace of the web is effectively doubling. For the uninitiated, this sounds like a recipe for "Broken Test Friday." In the old days of manual driver management, a faster release cadence meant more frequent SessionNotCreatedException errors and more time spent hunting for the right chromedriver binary to match your updated browser. +If you’ve been following the Chromium blog, you’ll have seen the news: Chrome is moving to a two-week release cycle. Starting in September 2026, the pace of the web is effectively doubling. In the old days of manual browser driver management, a faster release cadence meant more frequent SessionNotCreatedException errors and more time spent hunting for the right chromedriver binary to match your updated browser. But I’m here to tell you: Don’t panic. If you are using a modern version of Selenium (v4.11 or newer), this change is effectively a "non-event." Thanks to Selenium Manager, the days of manually synchronizing your browser and driver are over. @@ -34,54 +34,12 @@ Acquisition: If Chrome isn't found (or you need a specific version), it download Caching: It stores these in `~/.cache/selenium` so you aren't re-downloading them every time. -## What this looks like in practice +### What this looks like in practice -You don't need to change your code to handle the fortnightly updates. If you have a standard setup, it just works. Here is how it looks across the bindings: +You don't need to change your code to handle the two-week updates. Follow our [docs](https://www.selenium.dev/documentation/selenium_manager/#using-selenium-manager-from-the-bindings) on how to use it, including if you need to pin your tests to a specific version of Chrome. -Java -{{< tabpane langEqualsHeader=true >}} -{{< tab header="Java" >}} -// No System.setProperty needed for chromedriver -WebDriver driver = new ChromeDriver(); -// Selenium Manager automatically resolves the driver & browser behind the scenes. -{{< /tab >}} -{{< /tabpane >}} +## The Bottom Line -Python -{{< tabpane langEqualsHeader=true >}} -{{< tab header="Python" >}} -from selenium import webdriver - -# No executable_path required - -driver = webdriver.Chrome() - -# Even if Chrome updates every two weeks, Selenium Manager fetches the right bits - -{{< /tab >}} -{{< /tabpane >}} - -Taking Control of Versions -While Selenium Manager handles the "latest" version by default, the move to a fortnightly cycle might make you want to pin your versions to ensure stability across your CI/CD pipelines. You can do this easily through ChromeOptions: - -{{< tabpane langEqualsHeader=true >}} -{{< tab header="Python" >}} -from selenium import webdriver -from selenium.webdriver.chrome.options import Options - -options = Options() - -# Pin to a specific fortnightly release - -options.browser_version = "153" - -driver = webdriver.Chrome(options=options) -{{< /tab >}} -{{< /tabpane >}} - -In this scenario, Selenium Manager will see you want version 153, find the correct CfT binary, download it, and run your tests against that specific version—regardless of what the "regular" Chrome on your machine is doing. - -The Bottom Line The web is moving faster, and browser vendors are shipping features and security patches at an incredible rate. Our goal at Selenium is to ensure that the infrastructure of your tests remains invisible. The move to a two-week cycle is a testament to how far web engineering has come. With Selenium Manager, you can enjoy the benefits of a modern browser without the headache of manual maintenance.