as Tomo said: 1. version ranges make dependencies selection unstable: is it really necessary? (I personnally never use because of the build instability it adds, given I'm trying to go even beyond stable build: I'm working hard on Reproducible Builds [1]. Then my experience on detailed behaviour of such configuration is limited, sorry...)
2. this range includes versions such as "7.0.0-alpha" and "7.0.0-rc": from my experience on working on code for version comparison and version range, I imagine that when people write [..., 7.0.0-SNAPSHOT), what they really intent is to avoid even 7.0.0-alpha, beta, rc, then they should probably better write [..., 7.0.0-alpha-alpha) I know this is not fully intuitive. I remember some old discussions on defining some more precise semantics for version ranges, both for effective vs declared limits and SNAPSHOT inclusion of not, but IIRC this never went to an implementation My thoughts at that time is that Maven currently implements version ranges as pure mathematical range, where what people expect is not really math but something that will match an intent. Changes on version range use cases and semantic evolution are hard, we need to define what are the different intents, then how to express them, then implement, and avoid that Central Repository contains unusable libraries when we update version range semantics (= what we are currently tackling with Maven 3.7 work in progress): I know there are MNG issues and perhaps MRESOLVER ones, perhaps Wiki. Summarising links would already be a hard job... Hope this helps Regards, Hervé [1] https://issues.apache.org/jira/secure/ViewProfile.jspa?name=abrarovm Le mardi 10 novembre 2020, 16:34:21 CET Maxim Solodovnik a écrit : > Thanks for the quick answer Tomo, > > According to out build logs (available for ex. here [1]) > `7.0.0-SNAPSHOT` in the range results in checking all snapshot versions in > all snapshot repositories available > > so 6.7.1-SNAPSHOT, 6.7.2-SNAPSHOT, 6.7.3-SNAPSHOT etc are being checked ... > Is this expected > > https://ci-builds.apache.org/job/OpenMeetings/job/openmeetings/133/consoleFu > ll > > > > On Tue, 10 Nov 2020 at 21:49, Tomo Suzuki <suzt...@google.com.invalid> > > wrote: > > I avoid using version ranges because it introduces unexpected results in > > the dependency graphs. > > > > > [6.7.0,7.0.0-SNAPSHOT) > > > > I felt the intention of the range is the highest version before > > 7.0.0-SNAPSHOT (without including 7.0.0-SNAPSHOT version). > > As per [1], this range includes versions such as "7.0.0-alpha" and > > "7.0.0-rc". > > > > [1]: > > > > https://maven.apache.org/ref/3.6.3/maven-artifact/apidocs/org/apache/maven > > /artifact/versioning/ComparableVersion.html , > > > > > > > > On Tue, Nov 10, 2020 at 8:54 AM Maxim Solodovnik <solomax...@gmail.com> > > > > wrote: > > > Hello Maven experts, > > > > > > one sub-dependencies of our project has following > > > > > > <version>[6.7.0,7.0.0-SNAPSHOT)</version> > > > > > > [1] > > > > > > as a result metadata for all available SNAPSHOT version is being checked > > > > in > > > > > all SNAPSHOT repositories > > > this takes time > > > (full story is here https://groups.google.com/g/kurento/c/7B5k_cZ2Ya0) > > > > > > this is reproducible using both local build and build at > > > ci-builds.apache.org > > > > > > Is this expected behavior? > > > Is it Ok to use range dependency with SNAPSHOT in release version of > > > library? > > > > > > > > > > > > [1] > > > > https://repo1.maven.org/maven2/org/kurento/kms-api-elements/6.15.0/kms-api > > -elements-6.15.0.pom> > > > -- > > > Best regards, > > > Maxim > > > > -- > > Regards, > > Tomo --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
