Please set appropriate version on selenium rather than range to 4.7.2 as of current usage

[hazendaz]

It is not normal that poms have ranges for library usage which makes usage unstable generally when it gets whatever during run in that range that is available. Please define those with current selenium version instead so consumers don't get surprised by updated ranges that may be incompatible.

    <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-api</artifactId>
      <version>[4.7.0, 5.0)</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-remote-driver</artifactId>
      <version>[4.7.0, 5.0)</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-support</artifactId>
      <version>[4.7.0, 5.0)</version>
      <scope>runtime</scope>
    </dependency>

would be much better as

    <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-api</artifactId>
      <version>4.7.2</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-remote-driver</artifactId>
      <version>4.7.2</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.seleniumhq.selenium</groupId>
      <artifactId>selenium-support</artifactId>
      <version>4.7.2</version>
      <scope>runtime</scope>
    </dependency>

[valfirst]

@hazendaz could you please clarify why it's an issue for you? do new Selenium versions bring some issues/problems? have you tried managing Selenium version on your side?

[nir-tal-talkspace]

@valfirst this issue answers your question - SeleniumHQ/selenium#11453
it's impossible to pin a selenium version when Appium uses ranges,
and yes sometimes new selenium versions are buggy.

[mykola-mokhnach]

Not sure what "impossible to pin" means. Do you have an example?

The idea there is that we do not have to publish a new java client version after a new selenium release is done. An end user can always decide which particular dependency version to use in their codebase: https://docs.gradle.org/current/userguide/dependency_capability_conflict.html#sub:declaring-component-capabilities

[nir-tal-talkspace]

@mykola-mokhnach
the example:
selenium released 4.7.1 which had this devtools bug:
SeleniumHQ/selenium#11401

I am using a multi-module maven project
one module requires selenium only
and I was not affected because for this module selenium version did not change from 4.7.0

in the other module, I am doing cross-platform testing with appium and selenium and using devtools
all my mobile tests failed due to this issue, selenium version bumped to 4.7.1

1. I used the dependency management tag in the pom.xml for Selenium to try to pin the Selenium version, did not help
2. try to exclude selenium from Appium dependency - did not help also.

so all of my mobile efforts were terminated - because of an unwanted version bump that I could not stop.

[mykola-mokhnach]

I don't know how to help you with maven. I personally find it pretty much limited in comparison to Gradle.
Maybe try to reach specialized maven forums to get more info about enforcing transitive dependency versions.

[nir-tal-talkspace]

Maven is much more common than Gradle - spicily for automation engineers - and it's not possible to change the version if Appium selects ranges for selenium.

this change took me by surprise - I would at least document it.

[valfirst]

@nir-tal-talkspace could please provide a sample maven project to reproduce your problem? my assumption is it can be fixed by proper maven configuration

[hazendaz]

It is not a common use case or even suggested with maven to put version ranges into consumer poms. Maven does not have a lock feature such as NPM has. With more and more products running close to delivery, having unpinned dependencies affect builds that often result in failure as a result (certainly more recently with selenium), this results in having to take additional measures into account to protect from this bad behavior.

Its certainly fine if appium wants to claim its good for a version range. But don't express it this way. Document that on appium readme or user guides. In our case, we were already using selenium latest, but new version was released and since we did not have measures in place, our existing builds started failing once binaries were available. We do not expect that. We were not prepared for that sudden undisclosed change. It took deep diving dependency resolutions to see where this all went wrong.

To resolve the issue, and I'm sure most maven users are now having to do this, we have to exclude selenium from the appium dependency so the version range does not happen. It would be preferable to set that properly and no one is asking for constant releases. Maven itself does not suggest doing this and I think it would be hard pressed to find other projects doing such a thing.

[hazendaz]

To that end, if you want appium to just state 4.7.0, then do so. It just should not version range anything 4.7.0 to 5. We don't want 4.8 surprises or 4.7.3 surprises, etc. We want it effectively pinned to what you in fact tested and released on.

[hazendaz]

Article on why pinning is important may help https://betterdev.blog/pin-exact-dependency-versions/. Note on there they state maven doesn't typically have this issue, that is true, that is why this ticket was opened, this is not normal for maven.

[hazendaz]

@mykola-mokhnach @nir-tal-talkspace Its not impossible to pin but requires exclusions that should not be necessary and redefining properly pinned. We should not need to go to such an extent. Maven uses a complex resolution has to resolve with dependency management, dependency blocks, order, etc to resolve to a proper version. When a range is in place, it causes all kinds of problems. Some tools that run checks on versions tend to have issues in this case. Its so rare to ever see this in Maven. I've seen it twice in last 13 years. Its far better to just document on the project it works with XYZ version(s) and not impose that same logic onto poms. The ranges end up messing with resolution expectations. So say we were on selenium 4.7.0, didn't exclude, it will cause strange resolution that mixes selenium on the modules. They changed a good bit recently. Mixed versions lead to failures.

[hazendaz]

@valfirst @mykola-mokhnach

Nothing personal here, just hear me out again please.

Can we reopen this ticket? The issue was not resolved. When you make a consumer pom (end user) have version ranges in the pom, it causes issues for the consumers. Out of thousands of OSS components I'm aware of none currently other than this project doing this. Its done on exactly 3 items only.

• selenium-api
• selenium-remote-driver
• selenium-support

To use this library we have to set an immediate exclusion on all three which is not normal. With selenium dropping direct chrome support far too frequently, the hit is very negative and unstable if we don't exclude this poor provision.

As I had noted before, no one is asking for constant releases. We just do NOT need maven poms set to version ranges. Its poor practice and is not advised by maven at all. It will cause resolution issues for any teams that miss this fact which is why the ticket was raised. All that was done was to write documentation on that. That didn't solve anything. Sure that tells someone what you support and that is perfectly ok but please lock the versions to specific at time of your release. We don't much care what that is, just don't leave it wide open like this.

In fact, I procured this for our firm and it brought in selenium 4.10.0. That is part of the problem. Selenium 4.10.0 dropped chrome 111 already. And based on timing I'm pretty sure you were not expecting that either. I mean, come on, you released on 6/2, selenium released 6.10.0 today, why am I suddenly hooked on their new release due to this?

Think another way please. You have not done this with commons-io, gson, commons-validator, commans-lang3, or slfj4-api. Those are locked to version you released with. Maven users can override but we should not be forced to exclude bad behavior. For example, should you be releasing again because commons-io released today a regression fix? No, we can override that without writing exclusions at all. In fact already did but we still face issue here. And now we have selenium 4.10.0 pulled in our systems and we are not ready for it so our bots will now nag users to upgrade and further degrade usage. Let us degrade ourselves rather than forcing that on us please.

So, if 4.9.1 is what you want the poms to say, then please just say that in the pom. Please help us out here.

So to better make it clear

pom should not have

<version>[4.9.1, 5.0)</version>

It should just state

<version>4.9.1</version>

As every single other pom entry does.