Why dynamic version ranges in Maven are not as useful as originally intended?

Question

I've always been using explicit versions for Java dependencies in Maven/POM.

Then for a short time I switched to Python where I've learned that dependency version ranges (e.g. >=2.3.0) are quite popular and seems like limiting problems of dependency conflicts: chances are higher that two ranges overlap than that two exact versions are equal. I wondered why such a solution does not exist in Maven/POM world?

Then I got notifications about vulnerability in one my GitHub project dependencies and a suggestion to upgrade it to:

<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>[2.9.9,)</version>
</dependency>

Great, I thought, so there are dependency version ranges in Maven! I won't need to update my dependencies that often. But then, I read that they are de facto depracated, because:

• they are not as useful as originally intended, and also that they are unlikely to get improvements without a significant re-think.

• and that

  Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary

  but there seems to be the bug there (raised in 2007 and reopened in 2018).

Why they are not as useful as originally intended?

Are there alternative frameworks for Java, other than Maven, that handle dependency version ranges?

Answer 1

Other option is Gradle. From its docs "If the dependency is declared as a dynamic version (like 1.+, [1.0,), [1.0, 2.0)), Gradle will resolve this to the highest available concrete version (like 1.2) in the repository"