|
16 | 16 | // specific language governing permissions and limitations
|
17 | 17 | // under the License.
|
18 | 18 |
|
19 |
| -Solr has lots of 3rd party dependencies, defined mainly in `versions.props`. |
| 19 | +Solr has lots of 3rd party dependencies, defined in `gradle/libs.versions.toml`. |
20 | 20 | Keeping them up-to-date is crucial for a number of reasons:
|
21 | 21 |
|
22 | 22 | * minimizing the risk of critical CVE vulnerabilities by staying on a recent and supported version
|
23 | 23 | * avoiding "dependency hell", that can arise from falling too far behind
|
24 | 24 |
|
25 |
| -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 |
26 |
| -https://github.com/palantir/gradle-consistent-versions[Gradle consistent-versions] plugin. |
| 25 | +Read the https://github.com/apache/solr/blob/main/help/dependencies.txt[help/dependencies.txt] file for an in-depth |
| 26 | +explanation of how dependencies are managed. |
27 | 27 |
|
28 | 28 | == Manual dependency upgrades
|
29 | 29 | In order to upgrade a dependency, you need to run through a number of steps:
|
30 | 30 |
|
31 | 31 | 1. Identify the available versions from e.g. https://search.maven.org[Maven Central]
|
32 |
| -2. Update the version in `versions.props` file |
33 |
| -3. Run `./gradlew --write-locks` to re-generate `versions.lock`. Note that this may cause a cascading effect where |
| 32 | +2. Update the version in `gradle/libs.versions.toml` file |
| 33 | +3. Run `./gradlew writeLocks` to re-generate `versions.lock`. Note that this may cause a cascading effect where |
34 | 34 | the locked version of other dependencies also change.
|
35 |
| -4. Run `./gradlew updateLicenses` to re-generate SHA1 checksums of the new jar files. |
36 |
| -5. Once in a while, a new version of a dependency will transitively bring in brand-new dependencies. |
| 35 | +4. In case of a conflict, resolve the conflict according to `help/dependencies.txt` |
| 36 | +5. Check if there are any constraints that are obsolete after the dependency update |
| 37 | +6. Update the license and notice files of the changed dependencies. See `help/dependencies.txt` for |
| 38 | + details. |
| 39 | +7. Run `./gradlew updateLicenses` to re-generate SHA1 checksums of the new jar files. |
| 40 | +8. Once in a while, a new version of a dependency will transitively bring in brand-new dependencies. |
37 | 41 | You'll need to decide whether to keep or exclude them. See `help/dependencies.txt` for details.
|
38 | 42 |
|
| 43 | +=== Reviewing Constraints |
| 44 | + |
| 45 | +The constraints are defined in gradle/validation/dependencies.gradle. There, if the updated dependency is listed, |
| 46 | +the constraint can be reviewed, updated or removed. |
| 47 | + |
| 48 | +The constraints fall into two "groups". In the first group there are dependency constraints from dependencies |
| 49 | +that our project directly includes and require version alignment to sync the versions across all transitive |
| 50 | +dependencies. In the second group are dependencies that are only present as transitive dependencies. |
| 51 | +There, we try to follow the convention to provide additional information with "which dependencies use what version", |
| 52 | +so that the next person reviewing the constraint does not have to look it up. However, this is quite time-consuming |
| 53 | +to analyze the dependencies and therefore subject to change. |
| 54 | + |
| 55 | +In order to review a constraint, you have to check if the updated dependency is mentioned in any of the constraints, |
| 56 | +either as a reason for another dependency constraint or as the constraint's dependency. Removing temporarily |
| 57 | +a constraint, the task writeLocks will fail if the constraint is still required. |
| 58 | + |
| 59 | +This process and the constraints of dependencies.gradle are not optimal, as it is quite time-consuming and not obvious |
| 60 | +by just looking at it. We just haven't found yet a more efficient way to maintain these constraints. |
| 61 | + |
39 | 62 | == Renovate bot Pull Requests
|
| 63 | + |
| 64 | +The renovate bot may be replaced in the future with dependabot and this section may only be relevant for older |
| 65 | +versions (<10.0). See https://lists.apache.org/thread/1sb9ttv3lp57z2yod1htx1fykp5sj73z for updates. |
| 66 | + |
40 | 67 | A member of the Solr community operates a Github bot running https://github.com/renovatebot/renovate[Renovate], which
|
41 | 68 | files Pull Requests to Solr with dependency upgrade proposals. The PRs are labeled `dependencies` and do include
|
42 |
| -changes resulting from `gradle --write-locks` and `updateLicenses`. |
| 69 | +changes resulting from `./gradlew writeLocks` and `updateLicenses`. |
43 | 70 |
|
44 | 71 | Community members and committers can then review, and if manual changes are needed, help bring the PR to completion.
|
45 | 72 | For many dependencies, a changelog is included in the PR text, which may help guide the upgrade decision.
|
|
0 commit comments