erdi
commented
1 year ago Selenium has been very good at not introducing breaking API changes in minor releases and I don't see a reason why this would have changed in particular for the 4.x line. Geb has only a compile dependency on org.seleniumhq.selenium:selenium-api on purpose. I believe that there should be no reason why Geb 7.0 would not work with latest versions of selenium 4.x even though it was compiled against org.seleniumhq.selenium:selenium-api:4.2.2.
If you wish to use Geb with Selenium 4.6+ then I would first try it out rather than assume that it's not compatible for some reason. If it indeed is incompatible then please report back what the incompatibility is and I will see what we can do about it. One way or another I will be very surprised if a major breaking change is introduced, major enough to warrant a major release of Geb - the two things you mentioned are not major enough for me, one is a removal of a deprecated method with a straightforward replacement and for the other there is nothing in Geb that depends on the old protocol, everything has been switched to W3C as part of the switch to 4.x. There is a high chance of the upgrade will break things in Geb's own test suite because it uses advanced WebDriver features but that's somehow expected.
SeleniumManager was released at the end of last year in Selenium 4.6. It would help make Geb a little more "batteries included" and simplify browser testing a bit, so it seemed sensible to update. Of course, there have been plenty of other improvements in Selenium and especially Selenium's Java release in the releases since. Continued improvements in WebDriver-BiDi support in later releases may be relevant to a lot of use cases.
While not really a feature or bugfix, I assumed based on the CONTRIBUTING.md guide that this would be worth raising an issue to discuss.
Given that Selenium is a key part of the API and there have been breaking API changes in the releases since, I assume that upgrading Selenium would be a major version change for Geb. Changes to headless support and final removal of the JSON Wire protocol might be perceived as breaking changes by some users, for example.
Naturally, there will need to be fixes for moved APIs, broken tests, and all the normal parts of upgrading a major dependency. it would probably be prudent to test the new version in the example repositories in the Geb project as well.
Are there any other considerations to making a PR with a change this large? I don't expect to get to it soon, though I am angling for some time to work on this in October.