Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong version comparison for Spring Framework #73

Closed
pkubowicz opened this issue Aug 7, 2015 · 3 comments
Closed

Wrong version comparison for Spring Framework #73

pkubowicz opened this issue Aug 7, 2015 · 3 comments

Comments

@pkubowicz
Copy link
Contributor

build.gradle:

buildscript {
    repositories {
        jcenter()
    }

    dependencies {
        classpath 'com.github.ben-manes:gradle-versions-plugin:0.11.3'
    }
}

apply plugin: 'java'
apply plugin: 'com.github.ben-manes.versions'

repositories {
    mavenCentral()
}

dependencies {
    compile(group: 'org.springframework', name: 'spring-core', version:'4.2.0.RELEASE')
}

Buggy report:

% gradle depUp
:dependencyUpdates

------------------------------------------------------------
: Project Dependency Updates (report to plain text file)
------------------------------------------------------------

The following dependencies are using the latest milestone version:
 - com.github.ben-manes:gradle-versions-plugin:0.11.3

The following dependencies have later milestone versions:
 - org.springframework:spring-core [4.2.0.RELEASE -> 4.2.0.RC3]

4.2.0.RELEASE should be considered later than 4.2.0.RC3.

@ben-manes
Copy link
Owner

Unfortunately this is an issue with Ivy's implementation of the Maven versioning scheme. Since Gradle uses Ivy's comparitor and we use the one provided by Gradle for consistency, we inherit this bug. Ideally this issue should be fixed by Gradle as it also affects other usages such as version: '+' and component selection rules.

I'd like to see Gradle port Maven's ComparableVersion to follow its rules. There's been minor discussion by the Gradle team of making the comparator pluggable, since it currently doesn't follow the semantic versioning rules.

Please consider bringing this up on the Gradle forum. If enough people do maybe it will rise in their priority queue.

@pkubowicz
Copy link
Contributor Author

Thank you for the clarification. I opened a disussion on Gradle forum.

@ben-manes
Copy link
Owner

I'm going to close this as a Gradle problem that they have acknowledged, but not fixed. The best you can do is use a resolutionStrategy to reject release candidates, if desired. Otherwise its not a bug we can fix without rewriting Gradle's dependency management.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants