gus-asf commented on code in PR #2706: URL: https://github.com/apache/solr/pull/2706#discussion_r1840660878
########## dev-docs/dependency-upgrades.adoc: ########## @@ -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 Review Comment: Define necessary... ########## help/dependencies.txt: ########## @@ -100,12 +166,12 @@ If you want to upgrade Lucene to a newer build proceed like the following: queued) - remember the build number of Jenkins (left side, first build in list, prefixed by '#') -- Edit ./versions.props and change Lucene's version to '9.0.0-prereleaseX', +- Edit gradle/libs.versions.toml and change Lucene's version to '9.0.0-prereleaseX', Review Comment: When I look at versions.props we don't seem to be doing this. Is this a legacy from pre-split? Maybe this section should go away since Lucene definitely marches ahead on it's own now? (Main is not using 10.0 let alone a pre-release) ########## dev-docs/dependency-upgrades.adoc: ########## @@ -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 Review Comment: Check where? How does one identify an obsolete constraint? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
