Feature request: metadata for geckodriver versions

[bonigarcia]

Hello,

I am the creator of WebDriverManager, a helper library that automatically downloads the required drivers (like geckodriver) for Selenium. In addition, currently, I am implementing a tool called "Selenium Manager", which will be the official driver manager for the Selenium project.

In addition to geckodriver, the other two major drivers, i.e., chromedriver and msedgedriver, maintain some metadata for version discovery. For instance, the chromedriver team publishes several _LATESTRELEASE files on their website:

https://chromedriver.storage.googleapis.com/index.html

This way, to know the latest release of chromedriver, automated tools/scripts read the content of the following file:

https://chromedriver.storage.googleapis.com/LATEST_RELEASE

They also maintain specific metadata for browser versions. For instance, to find out the chromedriver version of a given version of Chrome (e.g., 105), we can read these kinds of files:

https://chromedriver.storage.googleapis.com/LATEST_RELEASE_105

This procedure was created some time ago (see info here). And after that, the msedgedriver did the equivalent (see here). For instance, the msedgedriver _LATESTRELEASE metadata looks like the following:

https://msedgedriver.azureedge.net/LATEST_RELEASE_105 https://msedgedriver.azureedge.net/LATEST_STABLE

This kind of metadata is very convenient for the so-called Selenium managers. Unfortunately, this info is not available for geckodriver. Although the release rate of geckodriver is lower than chromedriver and msedgedriver, it would be helpful to discover the latest version of geckodriver and the correct driver version for a given version of Firefox programmatically.

Please consider publishing the geckodriver versioning metadata in the same way that chromedriver and msedgedriver are already doing.

Thanks a lot in advance for your consideration!

PS: As an additional request, please keep the same file name pattern and compression format (i.e., geckodriver-v<VERSION>-linux32.tar.gz, geckodriver-v<VERSION>-linux64.tar.gz, geckodriver-v<VERSION>-macos-aarch64.tar.gz, geckodriver-v<VERSION>-macos.tar.gz, geckodriver-v<VERSION>-win32.zip, and geckodriver-v<VERSION>-win64.zip) for future releases of geckodriver, since changes on this might affect the behaviour of Selenium managers. Thanks again!

[whimboo]

Thanks for filing the issue @bonigarcia. Let me tackle both requests separately...

1) To get the latest version of geckodriver the GitHub API can be used to query for it. That's used by a lot of folks already and I wonder why this won't work for you.

2) geckodriver supports a wider range of Firefox releases and is not a 1-1 mapping to the underlying browser version. As such it's not enough to just put a version number into such a meta file. Instead it might be required to have a JSON file with minimum and maximum versions of the browser. Maybe we can drop the maximum given that this would require us to always have to update this file when a new Firefox release is shipped. Hm, maybe a meta file with the minimal version only?

[bonigarcia]

Thanks a lot for the feedback, @whimboo.

Regarding 1), indeed, I can calculate it from the GitHub API response. Moreover, I recently discovered that the URL https://github.com/mozilla/geckodriver/releases/latest redirects to the latest tag (v0.31.0 at the time of this writing). So yes, this can be automatically managed.

Regarding 2), the minimum supported version will do. I think it should not necessarily be a JSON. It may be a raw text file containing the minimum Firefox major version. But if you prefer a JSON for some reason, it will also work. This file will be an asset within each geckodriver release, right?

Many thanks again.

[whimboo]

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1794550 to handle that.

[bonigarcia]

Hi @whimboo. I don't see the JSON file in the geckodriver 0.32.0 assets. Is it going to be available there at some point for that release? Thanks

[whimboo]

Please see the referenced bug. We are actually not ready yet to ship such a file given that we are looking for a better place to host it. Hopefully we have a solution soon. Underlying reason is that at some point we do not want to have to go through releasing on GitHub but directly from our CI. And changing the location of the file later will cause trouble for various consumers.