TLC Meeting - June 25, 2026
Meetings are happening on the #selenium-tlc channel on Selenium Slack.
To add items to the agenda for the next meeting, please see our public Rolling Agenda
The next meeting will be Thursday, July 2 at 0700 Pacific / 1000 Eastern / 1500 UK / 1930 India.
Participation
Agenda
- Selenium 5 release charter
- ADR format and process updates
- BiDi implementation scope and Classic-command migration
- Selenium Manager API and possible Selenium CLI rebrand
- Public support boundaries for generated BiDi code and high-level APIs
Meeting Summary
The TLC focused on using ADRs to make Selenium 5 scope explicit and durable. The clearest outcomes were to narrow the current fallback requirement and to keep ADR reasoning in PRs or issue comments instead of relying on Slack history.
Decisions
- The group agreed that the release-charter draft should not keep a standalone Selenium 5 requirement for a per-command BiDi-to-Classic fallback. The fallback question can be handled as part of Classic-command migration work or revisited when concrete compatibility cases require it.
- The group agreed to prefer ADR comments and PR bodies for project decisions and supporting discussion, so the reasoning remains available after Slack history expires.
Discussion Notes
Selenium 5 Release Charter
diemol framed the release charter as a way to turn assumptions from past discussions into an explicit Selenium 5 plan. titusfortner explained that the intent is to use ADRs as the source of truth for what the TLC has agreed to support, what is in scope, and what is out of scope. The hard part is deciding the API contracts and compatibility expectations before the implementation spreads across bindings.
AutomatedTester was not present, so the group could not resolve the relationship between titusfortner’s release charter and AutomatedTester’s alternative API-layer proposal. titusfortner said he would continue that conversation outside the meeting and try to clarify the core difference.
BiDi Fallback And Classic-Command Migration
p0deje questioned whether fallback behavior should be a Selenium 5 release requirement if it is not itself a user-facing API. titusfortner explained that the idea came from previous discussion about handling browsers that support BiDi sessions but not every BiDi command, and described a Ruby proof of concept that retries unsupported commands through Classic HTTP.
pujagani and diemol raised concerns that browser behavior may not allow arbitrary command-by-command switching. pujagani noted that some Chrome behavior appears to require staying on the BiDi path for related operations, while Safari may ship partial BiDi support. diemol and p0deje also noted enterprise and remote-provider cases where WebSocket access or older browser versions could affect adoption. The group leaned toward treating fallback as part of the migration design, not as a standalone Selenium 5 release gate.
Selenium Manager API And CLI Scope
titusfortner said Selenium Manager needs clearer behavior before it is decoupled from binding releases, including what happens when a binding sends a command that a particular Selenium Manager binary does not recognize. p0deje and diemol asked whether Selenium Manager is already effectively public, because users can call the binary and the bindings expose wrapper behavior.
bonigarcia suggested that the project could rebrand Selenium Manager as Selenium CLI if it grows into broader capabilities such as AI or MCP integrations. diemol cautioned that the rebrand could expand Selenium 5 scope and preferred an incremental release approach. titusfortner will draft an ADR to make the Selenium Manager proposal concrete.
BiDi API Support Boundaries
p0deje summarized the open design question as a choice between exposing the whole generated BiDi protocol as public API or keeping it as internal implementation detail behind selected high-level APIs. titusfortner preferred a clearer boundary where generated protocol code can change with the spec, while stable user-facing APIs such as Network and Script are intentionally designed and supported.
The group discussed whether Python’s existing shape, AutomatedTester’s generated-code approach, and the desired protocol-neutral APIs are all compatible. titusfortner also raised concern that implementation work may be much easier in some bindings than in Java or Ruby, so the project needs cross-binding agreement before each binding runs too far ahead.
ADR Process
diemol recommended keeping substantive comments in ADRs rather than Slack so contributors can follow the reasoning later. pujagani agreed that Slack history disappears over time. titusfortner proposed ADR template changes that include a place for discussion summaries, possibly with AI assistance to move relevant Slack summaries into PR bodies.
Action Items
- diemol will update the documentation-plan filter noticed while reviewing the release-charter draft.
- titusfortner will update the Selenium 5 release-charter draft to remove or rework the standalone fallback requirement.
- titusfortner will draft an ADR for Selenium Manager API and release-decoupling behavior.
- titusfortner will continue the API-boundary discussion with AutomatedTester and try to distill the core disagreement for the TLC.
- TLC members will review the open ADR and release-charter PRs and approve, reject, or comment.
