> thoughts?

(I don't design or use Maven version ranges)
I agree that the behavior below, such as "5.0.0-SNAPSHOT" < "5", is not
intuitive for users.
Our team in Google recently articulated good practices of maintaining
dependencies. One of the topics is "not to use version range":
https://jlbp.dev/JLBP-14.html .


On Tue, Nov 26, 2019 at 7:09 AM Maarten Mulders <[email protected]> wrote:

> I've recently had the same line of thought...
>
> Many projects publishing "release candidates" or "milestone releases". I
> understand
> this is great for having feedback from their user base, but sometimes
> I'd rather use
> a "stable" version. Although this brings a new question to the table:
> who determines
> what is stable? In the end, it's the author(s) of those projects who
> decide that.
>
> Unfortunately, there seems not to be a default for releasing "release
> candidates"
> or "milestone releases".
>
> Cheers,
>
> Maarten
>
> On November 26, 2019 at 12:57, John Patrick wrote:
>
> > cheers for the information.
> >
> > I expect this might be asking space vs tabs, but do others feel the
> > version range of "[4,5)" should exclude anything starting 5, include
> > 5....-SNAPSHOT and any 5...-RC* or 5...-alpha
> >
> > It seams wrong to have to use "[4,4.9999999)".
> >
> > I understand from a maths point of view and from a order point of view
> > the ordering is correct but from an ease of use, end developers point
> > of view, i should just be able to use "[4,5)"
> >
> > thoughts?
> >
> > On Mon, 25 Nov 2019 at 20:40, Tomo Suzuki <[email protected]>
> > wrote:
> > I believe your cases do not work with version ranges. Version ranges
> > depend
> > on the order of the versions, and thus you cannot filter "-guava".
> >
> > The ordering of version is defined in
> > org.eclipse.aether.util.version.GenericVersion in maven-resolver-util.
> >
> > Example code to check:
> >
> > // GenericVersionScheme is in
> > org.apache.maven.resolver:maven-resolver-util:1.3.3
> > GenericVersionScheme scheme = new GenericVersionScheme();
> > List<Version> list = new ArrayList<>();
> > list.add(scheme.parseVersion("4.7.0"));
> > list.add(scheme.parseVersion("4.99999.0"));
> > list.add(scheme.parseVersion("5"));
> > list.add(scheme.parseVersion("5.0.0"));
> > list.add(scheme.parseVersion("5.0.0-RC1"));
> > list.add(scheme.parseVersion("5.0.0-SNAPSHOT"));
> > Collections.sort(list);
> > System.out.println(list); // [4.7.0, 4.99999.0, 5.0.0-RC1,
> > 5.0.0-SNAPSHOT, 5, 5.0.0]
> >
> > So version "5.0.0-RC1" is smaller than version "5"; you can use [4.7.0,
> > 4.9999999]".
> >
> > Regards,
> > Tomo
> >
> > On Sun, Nov 24, 2019 at 2:46 PM John Patrick <[email protected]>
> > wrote:
> >
> > i'm trying to start using maven version range more but having issues
> > with things like guava and also it not excluding version i believe
> > should be excluded.
> >
> > 1) i don't think this is possible but it might be, take a look a
> > google guava, it has a jre and a android version. using maven version
> > range how can i say any newer jre version, or any newer android
> > version?
> >
> > https://search.maven.org/artifact/com.google.guava/guava
> >
> > something like [25,) but only the jre maybe [25*-jre,)
> >
> > 2) i'm trying to use the version range "[4.7.0,5) "for
> > io.cucumber:cucumber-core. So i'm expecting it to use 4.8.0, not
> > 5.0.0-RC1 which is being picked up, i.e. mvn dependency:tree -Dverbose
> > -Dincludes=io.cucumber
> >
> > https://search.maven.org/artifact/io.cucumber/cucumber-core
> >
> > what do i need to change "[4.7.0,5)" to do it excludes anything
> > starting 5?
> >
> > or are other people having similar issue so gave using trying to use
> > maven version ranges when declaring dependencies?
> >
> > John
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> > --
> > Regards,
> > Tomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

-- 
Regards,
Tomo

Reply via email to