-
Notifications
You must be signed in to change notification settings - Fork 662
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
SOLR-17406: Introduce Version Catalogs #2706
base: main
Are you sure you want to change the base?
Changes from 37 commits
a0435d7
f3f9dc0
efdabc4
fedc606
961c2bd
c6a6933
2d44f04
5e05300
f50e2c7
c74bfec
867fb11
cb54484
0585bba
cdc843f
6abab94
db283a5
98ec23e
078ebbd
05d30f2
83819ef
5825de2
94d8ca6
eef39b2
48c21cc
50a4a81
b895992
101a323
6f92804
3212b5b
699480d
a0f4d1e
017fe17
6caff99
5824fdd
a763a69
7215a4c
b41e9e5
2b7519f
d876ea0
e55348a
4e269b8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -16,30 +16,34 @@ | |
// specific language governing permissions and limitations | ||
// under the License. | ||
|
||
Solr has lots of 3rd party dependencies, defined mainly in `versions.props`. | ||
Solr has lots of 3rd party dependencies, defined in `gradle/libs.versions.toml`. | ||
Keeping them up-to-date is crucial for a number of reasons: | ||
|
||
* minimizing the risk of critical CVE vulnerabilities by staying on a recent and supported version | ||
* avoiding "dependency hell", that can arise from falling too far behind | ||
|
||
Read the https://github.com/apache/solr/blob/main/help/dependencies.txt[help/dependencies.txt] file for an in-depth explanation of how gradle is deployed in Solr, using | ||
https://github.com/palantir/gradle-consistent-versions[Gradle consistent-versions] plugin. | ||
Read the https://github.com/apache/solr/blob/main/help/dependencies.txt[help/dependencies.txt] file for an in-depth | ||
explanation of how dependencies are managed. | ||
|
||
== Manual dependency upgrades | ||
In order to upgrade a dependency, you need to run through a number of steps: | ||
|
||
1. Identify the available versions from e.g. https://search.maven.org[Maven Central] | ||
2. Update the version in `versions.props` file | ||
3. Run `./gradlew --write-locks` to re-generate `versions.lock`. Note that this may cause a cascading effect where | ||
2. Update the version in `gradle/libs.versions.toml` file | ||
3. Run `./gradlew writeLocks` to re-generate `versions.lock`. Note that this may cause a cascading effect where | ||
the locked version of other dependencies also change. | ||
4. Run `./gradlew updateLicenses` to re-generate SHA1 checksums of the new jar files. | ||
5. Once in a while, a new version of a dependency will transitively bring in brand-new dependencies. | ||
4. In case of a conflict, resolve the conflict according to `help/dependencies.txt` | ||
5. Check if there are any constraints that are obsolete after the dependency update | ||
6. Update the license and notice files of the changed dependencies if necessary. See `help/dependencies.txt` for | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Define necessary... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Generally said, any difference in the LICENSE or NOTICE file of the affected dependencies is a change we have to include. Updating LICENSE and NOTICE files is also subject to change, see SOLR-15929. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is detail that should be provided in the doc so that there's no variation in what people think is "necessary", even if it's just a reference to the doc mentioned in that ticket. |
||
details. | ||
7. Run `./gradlew updateLicenses` to re-generate SHA1 checksums of the new jar files. | ||
8. Once in a while, a new version of a dependency will transitively bring in brand-new dependencies. | ||
You'll need to decide whether to keep or exclude them. See `help/dependencies.txt` for details. | ||
|
||
== Renovate bot Pull Requests | ||
A member of the Solr community operates a Github bot running https://github.com/renovatebot/renovate[Renovate], which | ||
files Pull Requests to Solr with dependency upgrade proposals. The PRs are labeled `dependencies` and do include | ||
changes resulting from `gradle --write-locks` and `updateLicenses`. | ||
changes resulting from `./gradlew writeLocks` and `updateLicenses`. | ||
|
||
Community members and committers can then review, and if manual changes are needed, help bring the PR to completion. | ||
For many dependencies, a changelog is included in the PR text, which may help guide the upgrade decision. | ||
|
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.
Check where? How does one identify an obsolete constraint?
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.
The constraints are defined in
gradle/validation/dependencies.gradle
. There, if the updated dependency is listed, the constraint can be reviewed, updated or removed.The constraints fall into two "groups". The first group are dependency constraints from dependencies that our project directly includes and require version alignment to sync the versions across all transitive dependencies.
The second group are dependencies that are only present as transitive dependencies. There, I followed the convention to provide additional information with "which dependencies use what version", so that the next person reviewing the constraint does not have to look it up. However, this is quite time-consuming to analyze the dependencies and therefore subject to change.
Now, in order to review a constraint, you have to check if the updated dependency is mentioned in any of the constraints, either as a reason for another dependency constraint or as the constraint's dependency. Removing temporarily a constraint, the task
writeLocks
will fail if the constraint is required.This process and the constraints of dependencies.gradle are not optimal, as it is quite time-consuming and not obvious by just looking at it. We just haven't found yet a more efficient way to maintain these constraints.
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 meant to imply that the documentation should answer these questions for the folks attempting to follow it :)