Chrome Driver dropping backwards compatibility?

[jram...@onshape.com]

Is backwards compatibility completely gone for Chrome Driver? I see with versions 73 and 74 they are only compatible with the corresponding Chrome version. This causes us a lot of issues:

1) Our test code is versioned and the version of chrome driver is driven by our package json
2) Our developers and QA run a multitude of machines and operating systems; with Chrome rolling out over time there is a period where the Chrome versions are not universal
3) Our selenium tests are important to our release process. As such, we validate Chrome and Chrome Driver updates independently in order to update the tools in our CI machines. We've had issues in the past with new Chrome versions breaking, which has made us hold off on updating from time to time.

Due to Chrome 74 just rolling out, we are in a period where test code is runnable for some but not others as people (and machines) are on a mismatch of Chrome versions.

Having a range of usable Chrome versions was immensely helpful and I would be disappointed if this were to be removed all together.

[geis...@gmail.com]

I understand your position, as many of us have dealt with the issues of incompatibility in our test harnesses because they have so many components.

So I will add this observation after 4 years of Web automation development testing:  Do not let Google update your Chrome installs without first a good regression test run.  There have been times when I have not moved my harness off of current Chrome for nearly a year while things became stable.

I fire up a VM with latest Chrome and driver and run a full regression before I release into my production test harness.  (As an example currently Chrome 74 and driver 74 break my Web automation when it is started by Jenkins.  So I am staying on 73 for now.)

If you can not do something like this you will experience a lot of pain.  Especially since Google does not make old versions of Chrome available.  (I store off installed copies in tar balls for this reason)

As far as backwards compatibility it has a lot of down sides.  Especially for open-source products with limited development resources.

[John Chen]

Backward compatibility was dropped from ChromeDriver for a couple of reasons:

• It adds complexity to the code, and is expensive to maintain.
• It requires an infrastructure to test each build of ChromeDriver against multiple versions of Chrome. There is no such requirement anywhere else inside Chrome, and it became increasingly difficult to convince our build team to maintain such an infrastructure just for ChromeDriver.

I understand this creates difficulty for some of our users, but unfortunately it has become impossible for us to keep supporting the backward compatibility.

--
You received this message because you are subscribed to the Google Groups "ChromeDriver Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromedriver-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[JordanW EBEInc]

So every month, automated processes are now manual? ChromeDriver 2.37 is working fine with Chrome version 89 still. So I imagine this being a hardcoded limitation?

If backwards compatibility is removed, then have it download the needed driver instead? Allow it to run, and ignore version check?

If an app breaks monthly, telling a user to stop upgrading sounds counter-intuitive to the design of that app?