-
Notifications
You must be signed in to change notification settings - Fork 715
SOLR-15854: Upgrade semver library to fix versioning constraint bugs in the PackageManager. #515
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
Conversation
This is kind of a pain, but I’d like to see the commits split into a clean fork and then our changes separately. Also, I don’t think we repackage the files, see org.noggit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked forever too without finding a good, maintained library. I checked the forks etc. Also checked a few Kotlin libs but they tend to have less features.
I really don't like forking that amount of code into the project, it will for sure rot in here.
solr/core/src/java/org/apache/solr/packagemanager/PackageUtils.java
Outdated
Show resolved
Hide resolved
There are already 11 contributors to https://github.com/vdurmont/semver4j. Have you tried contacting them? Perhspa if we submit a PR for vdurmont/semver4j#48 and ping a few of the devs, we can help trigger a new release? Two years old can also mean that it is mature and don't need that many updates... |
Maybe for an adjacent library, just having a fixed version that lives as someone's personal fork in Github would also be okay? Versus bringing in this code to the Solr project itself. Github makes it too easy to get lots of forks that all end up vaguely unmaintained, and I wish it encouraged a cluster of forks like what we see for semver to somehow come back together to a single maintained approach. Oh wait... community over code ;-) |
Completely agree with both of you that not forking would be the best path forward. It's hard company-policy-wise for me to move forward with either of those options, but I would appreciate either of you taking it up! |
I'll not veto the code copy, if you clearly mark it and open, say, a blocker JIRA for 10.0 or something to replace it with something that is maintained... |
Looks like this was fixed and forked - https://github.com/semver4j/semver4j potentially? |
I updated this PR with my changes. I realized I didn't need a new PR since I was able to merge main and then use semver4j. I need to fix a few things still solr/CHANGES.txt and maybe some other minor things, but overall this is ready to go. |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, looks good. Fingers crossed that this gets maintained. GitHub projects cold learn a lot form ASF wrt adding committers and caring about project community health.
…in the PackageManager. (#515) Co-authored-by: Kevin Risden <[email protected]>
apache#515 follow-up: wget https://raw.githubusercontent.com/semver4j/semver4j/v2.1.1/LICENSE mv LICENSE solr/licenses/semver4j-LICENSE-MIT.txt
…#1086) #515 follow-up: wget https://raw.githubusercontent.com/semver4j/semver4j/v2.1.1/LICENSE mv LICENSE solr/licenses/semver4j-LICENSE-MIT.txt
…#1086) #515 follow-up: wget https://raw.githubusercontent.com/semver4j/semver4j/v2.1.1/LICENSE mv LICENSE solr/licenses/semver4j-LICENSE-MIT.txt (cherry picked from commit c96c781)
https://issues.apache.org/jira/browse/SOLR-15910