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

Documentation / Skip non-stable versions #834

Closed
wants to merge 1 commit into from

Conversation

johnjohndoe
Copy link
Contributor

I tried to extend the rejection rule to exclude versions like org.jetbrains.kotlin:kotlin-stdlib [1.9.22 -> 2.0.0-Beta3] but for some reason it is still listed.
Do you spot the mistake?

I tried to extend the rejection rule to exclude versions like `org.jetbrains.kotlin:kotlin-stdlib [1.9.22 -> 2.0.0-Beta3]` but for some reason it is still listed. Do you spot the mistake?
@ben-manes
Copy link
Owner

You might see if my build snippet from Caffeine helps? I added an unstableKeyword and return that in the condition. I'm not sure why yours didn't work as the two look very similar in concept.

@ben-manes
Copy link
Owner

trying your version in a groovy repl and it seems like it should work....

def isNonStable = { String version ->
  def nonStableKeyword = ["BETA"].any { it -> version.toUpperCase().contains(it) }
  if (nonStableKeyword) {
    return true
  }
  def stableKeyword = ['RELEASE', 'FINAL', 'GA'].any { it -> version.toUpperCase().contains(it) }
  def regex = /^[0-9,.v-]+(-r)?$/
  return !stableKeyword && !(version ==~ regex)
}

println(isNonStable("2.0.0-Beta3"))
println(isNonStable("1.9.22"))
true
false

@johnjohndoe
Copy link
Contributor Author

Yes, it seem to be correct. When I apply it to my project still the beta version is printed out when run the plugin task:

 - org.jetbrains.kotlin:kotlin-stdlib [1.9.22 -> 2.0.0-Beta3]
     https://kotlinlang.org/

@ben-manes
Copy link
Owner

I took that snippet into a sample project and it came out as you desired. This PR actually isn't needed because the keyword search is for stable or numeric, and anything else is assumed unstable to be excluded. So beta should have been dropped. However, I also see in your build it shows up which is weird, but I haven't looked into it much yet.

sample
plugins {
  id 'com.github.ben-manes.versions' version '0.51.0'
  id 'java'
}

repositories {
  mavenCentral()
}

dependencyUpdates {
  def isNonStable = { String version ->
    def stableKeyword = ['RELEASE', 'FINAL', 'GA'].any {
      qualifier -> version.toUpperCase().contains(qualifier)
    }
    def regex = /^[0-9,.v-]+(-r)?$/
    return !stableKeyword && !(version ==~ regex)
  }
  rejectVersionIf {
    return isNonStable(it.candidate.version)
  }
}

dependencies {
  implementation 'org.jetbrains.kotlin:kotlin-stdlib:1.9.22'
}
gradle dU --refresh-dependencies -q
executing gradlew instead of gradle

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

The following dependencies are using the latest milestone version:
 - com.github.ben-manes.versions:com.github.ben-manes.versions.gradle.plugin:0.51.0
 - org.jetbrains.kotlin:kotlin-stdlib:1.9.22

Gradle release-candidate updates:
 - Gradle: [8.0.2 -> 8.6]

@ben-manes
Copy link
Owner

A println shows it rejections,

Selection of org.jetbrains.kotlin:kotlin-stdlib:2.0.0-Beta3 rejected by component selection rule: Rejected by rejectVersionIf

but then I also observe,

Comparing dependency (current: org.jetbrains.kotlin:kotlin-stdlib:2.0.0-Beta3, latest: 2.0.0-Beta3)

Which indicates a dynamic version somewhere on the declared dependencies, and that is somehow not applying the resolution strategy.

Unfortunately I'm not sure beyond that. It is a configuration in the app subproject, but it does not print out which one. I don't know why it is not being constrained by Gradle.

@ben-manes
Copy link
Owner

oh, this is the regression in #733. We might just want to revert the contributed changes (#733 (comment)). I never had a chance to look into it and see if the contributor's improvements could be reworked to not cause this breakage. If I use v0.45 in your project then you get the right output.

I'll close pr. There is a workaround in that issue. It would be good to fix but it's not something I have the time to investigate unfortunately.

@ben-manes ben-manes closed this Feb 9, 2024
@johnjohndoe
Copy link
Contributor Author

Thank you for looking into it. I agree that at this point it might not be worth the time. We have it documented here so it is easy to pick up in the future.

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

Successfully merging this pull request may close these issues.

None yet

2 participants