SeleniumHQ
[🚀 Feature]: Change Selenium Versioning
Feature and motivation
People expect that backwards incompatible changes only happen on Major releases.
I propose that starting with Selenium 5, we do: Major releases — All bindings released (similar to minor release today) Minor releases — Language specific features that get added Patch releases — Language specific bug fixes
So we will do Selenium 6 instead of Selenium 5.1 etc.
We should still give plenty of warning when we deprecate existing behavior. I'm not sure if we want to tie it to a version release (current release + 2), or tie it to a timeframe (3+ months), but that's another discussion.
Usage example
n/a
I think this is really bad idea. Selenium project produces just a library, it is not a big portable product/service/program. This is a library, similar as tons of other libraries! People will not upgrade to v120.0.0 from v115.0.1 because it is risky "semantically".
What I hear from initial request: provide an ability to develop language bindings independently with separate release cycle. If it is a case, then I vote to: "Let a development of bindings to be completely separated". I don't see a reason why major version of all bindings should be the same. If Java implements BiDi - go ahead! Release it!
Many of the things we're doing is because this is one project not seven separate projects. This matters, and keeping versions synchronized I think is very important.
This is a good article: https://tom.preston-werner.com/2022/05/23/major-version-numbers-are-not-sacred.html
We've been using major versions to discuss large marketing/architecture changes rather than using it for breaking changes. Though, to be fair, we've spent a lot of time (too much) over the years trying to minimize breaking changes. People already aren't updating as fast as we'd like them to (lots of people still on 3.x), either they are focused on keeping up to date or they aren't, and I'm not sure how hesitant people would be under the new pace vs the old.
I don't have opinion about this change, but some input from my side.
People expect that backwards incompatible changes only happen on Major releases.
This could lead to major versions without breaking changes for some bindings, this could be confusing for users too.
People already aren't updating as fast as we'd like them to (lots of people still on 3.x), either they are focused on keeping up to date or they aren't, and I'm not sure how hesitant people would be under the new pace vs the old.
How about adding a timestamp to the version {major}.{minour}.{patch}-{year}-{month}-{day}? This might help users to realize they a using a X years old version.
Any versioning scheme should be meaningful. The issue here is every binding wants a separate release cycle.
What about {year}.{month}.{patch}? where patch is controlled by language binding
Edit: I am reading this comment, and in .net world I don't want to have year as major.