Consider adding a meta file as release asset that contains the oldest supported Firefox release
Categories
(Testing :: geckodriver, task, P3)
Tracking
(Not tracked)
People
(Reporter: whimboo, Assigned: whimboo, NeedInfo)
References
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Originally filed as: https://github.com/mozilla/geckodriver/issues/2049
The idea for the Selenium project is to have an automated way to check for the minimum Firefox release that a geckodriver release actually supports. Right now this information is only available in our support document.
My proposal would be to have a meta file as a release asset similar to the downloadable archived binaries and source files. That way we could still update it post-release in case that something inappropriately broke for older releases of Firefox.
The questions that we have to solve now are the name of the file and its contents. As requested it should not necessarily be a JSON file. Plain text would be fine given that we only have to provide the oldest Firefox release that a geckodriver release actually supports. I would propose the following:
support.txt
102
The version should not necessarily contain minor release version numbers and also not a esr
suffix.
James, do you have any other feedback or comments? I would like to get this added for the upcoming 0.32.0 release.
Assignee | ||
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Given that we're also documenting a max version for older geckodriver releases, it seems very odd to not make the format more flexible, and allow more than one field. So support.json
with something like {"min": "102.0", "max": "107.0"}
makes more sense (obviously we'd mostly end up adding the max version after the release). Also the version number should be a string and include a dot so that people don't try to parse it using int(version)
and get surprised if later on we need to refer to a dot release for any reason.
To cut down manual work, I'd suggest we stop putting this information directly in the release notes if we're going to provide it in a machine readable fashion.
Assignee | ||
Comment 2•2 years ago
|
||
Further discussed with James on Element and we agreed on the JSON-format approach. Hereby we will leave out the maxVersion
for now given that it would cause us to run numerous updates on the release assets for previous releases. If needed we could have a script in the future that could set the versions. Alternatively there would be the option to have a single support.json
file only that contains all the geckodriver releases with appropriate min and max versions of Firefox. It should be at a location where we can easily and quickly update it even for previous releases in case of a new max criteria.
Assignee | ||
Comment 3•2 years ago
|
||
Depends on D159030
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
As it can be seen in the review more work would be necessary here. If we want to use TaskCluster for the JSON file then we have to schedule this work accordingly.
Comment 5•2 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1372587#c6 for how to release artifacts on archive.m.o
Assignee | ||
Comment 6•2 years ago
|
||
As discussed today we have to clarify how much work it would be to eg. get our own folder on archive.mozilla.org like https://archive.mozilla.org/pub/geckodriver/
. Then we could put such a version / support JSON file directly under this location.
We will need credentials to push to this directory, which then should also work out-of-band from geckodriver releases because the maximum supported version of Firefox could change and would require an immediate update.
As best we should follow-up on the comment James' referenced in his last comment. I'll have a look as soon as I can.
Comment 7•2 years ago
|
||
Clearing the flag, while henrik has a needinfo, feel free to add it back
Comment 8•1 year ago
|
||
Is there any news regarding this issue? Thanks a lot!
Description
•