|
|
|
 |
- last updated a few seconds ago
Thursday 19 Dec 2019
-
-
… 415 more files in
changeset.
Tuesday 17 Dec 2019
Remove version constrain constructor without 'branch' Although technically the 'branch' is special as it is not (yet) published and thus not used/needed in many places, we keep things consistent to avoid weird issues as the one fixed in the previous commit.
-
-
… 7 more files in
changeset.
Remove version constrain constructor without 'branch' Although technically the 'branch' is special as it is not (yet) published and thus not used/needed in many places, we keep things consistent to avoid weird issues as the one fixed in the previous commit.
-
-
… 6 more files in
changeset.
Tuesday 17 Sep 2019
Rename inheritStrictVersions() -> endorseStrictVersions() (#10755) This name change more clearly communicates the semantics of the feature from a users point of view. This commit also removes all mentions of 'inheriting' AND 'forSubgraph'. There have been some leftovers in documentation/comments that would have been misleading in the future. To make sure we catch all, this also updates all variable/method/package names.
-
-
… 70 more files in
changeset.
Rename inheritStrictVersions() -> endorseStrictVersions() This is more clearly communicating the semantics of the feature from a users point of view. The commit also removes all mentions of 'inheriting' AND 'forSubgraph'. There have been some leftovers in documentation/comments that will be misleading in the future. To make sure we catch all, I also updated all variable/method/package names.
-
-
… 70 more files in
changeset.
Rename inheritStrictVersions() -> endorseStrictVersions() This is more clearly communicating the semantics of the feature from a users point of view. The commit also removes all mentions of 'inheriting' AND 'forSubgraph'. There have been some leftovers in documentation/comments that will be misleading in the future. To make sure we catch all, I also updated all variable/method/package names.
-
-
… 70 more files in
changeset.
Rename inheritStrictVersions() -> endorseStrictVersions() This is more clearly communicating the semantics of the feature from a users point of view. The commit also removes all mentions of 'inheriting' AND 'forSubgraph'. There have been some leftovers in documentation/comments that will be misleading in the future. To make sure we catch all, I also updated all variable/method/package names.
-
-
… 70 more files in
changeset.
Tuesday 10 Sep 2019
Rework `forSubgraph` as implied by `strictly` This commit removes a dedicated `forSubgraph` flag on version constraints, so that it is _implied_ by strict version constraints. This simplifies the behavior of `strictly`, making it closer to the intuitive semantics, while maintaining the ability to fail the build if a consumer brings an incompatible version in the graph. As a consequence, _strict dependencies_ now express that the producer preference overrides whatever is found in its own dependency graph. It is closer to the "nearest first" semantics of Maven, while not having its drawbacks (ordering in particular).
-
-
… 77 more files in
changeset.
Rework `forSubgraph` as implied by `strictly` This commit removes a dedicated `forSubgraph` flag on version constraints, so that it is _implied_ by strict version constraints. This simplifies the behavior of `strictly`, making it closer to the intuitive semantics, while maintaining the ability to fail the build if a consumer brings an incompatible version in the graph. As a consequence, _strict dependencies_ now express that the producer preference overrides whatever is found in its own dependency graph. It is closer to the "nearest first" semantics of Maven, while not having its drawbacks (ordering in particular).
-
-
… 79 more files in
changeset.
Rework `forSubgraph` as implied by `strictly` This commit removes a dedicated `forSubgraph` flag on version constraints, so that it is _implied_ by strict version constraints. This simplifies the behavior of `strictly`, making it closer to the intuitive semantics, while maintaining the ability to fail the build if a consumer brings an incompatible version in the graph. As a consequence, _strict dependencies_ now express that the producer preference overrides whatever is found in its own dependency graph. It is closer to the "nearest first" semantics of Maven, while not having its drawbacks (ordering in particular).
-
-
… 77 more files in
changeset.
Rework `forSubgraph` as implied by `strictly` This commit removes a dedicated `forSubgraph` flag on version constraints, so that it is _implied_ by strict version constraints. This simplifies the behavior of `strictly`, making it closer to the intuitive semantics, while maintaining the ability to fail the build if a consumer brings an incompatible version in the graph. As a consequence, _strict dependencies_ now express that the producer preference overrides whatever is found in its own dependency graph. It is closer to the "nearest first" semantics of Maven, while not having its drawbacks (ordering in particular).
-
-
… 77 more files in
changeset.
Rework `forSubgraph` as implied by `strictly` This commit removes a dedicated `forSubgraph` flag on version constraints, so that it is _implied_ by strict version constraints. This simplifies the behavior of `strictly`, making it closer to the intuitive semantics, while maintaining the ability to fail the build if a consumer brings an incompatible version in the graph. As a consequence, _strict dependencies_ now express that the producer preference overrides whatever is found in its own dependency graph. It is closer to the "nearest first" semantics of Maven, while not having its drawbacks (ordering in particular).
-
-
… 77 more files in
changeset.
Rework `forSubgraph` as implied by `strictly` This commit removes a dedicated `forSubgraph` flag on version constraints, so that it is _implied_ by strict version constraints. This simplifies the behavior of `strictly`, making it closer to the intuitive semantics, while maintaining the ability to fail the build if a consumer brings an incompatible version in the graph. As a consequence, _strict dependencies_ now express that the producer preference overrides whatever is found in its own dependency graph. It is closer to the "nearest first" semantics of Maven, while not having its drawbacks (ordering in particular).
-
-
… 77 more files in
changeset.
Tuesday 23 Jul 2019
Add `forSubgraph()` API to version constraints
-
-
… 19 more files in
changeset.
Add `forSubgraph()` API to version constraints
-
-
… 19 more files in
changeset.
Add `forSubgraph()` API to version constraints
-
-
… 20 more files in
changeset.
Add `forSubgraph()` API to version constraints
-
-
… 20 more files in
changeset.
Add `forSubgraph()` API to version constraints
-
-
… 19 more files in
changeset.
Thursday 27 Jun 2019
Add `strong()` API to version constraints
-
-
… 16 more files in
changeset.
Tuesday 06 Nov 2018
Provide special display message for 'reject all'
-
-
… 4 more files in
changeset.
Friday 02 Nov 2018
Add useful displayName to `VersionConstraint`
-
-
… 3 more files in
changeset.
Sunday 16 Sep 2018
Don't implicitly add 'prefer' with 'require'
-
-
… 11 more files in
changeset.
Sunday 29 Jul 2018
Ensure that 'preferredVersion' always provides a useful value Recent versions of the build scan plugin depend on `VersionConstraint.preferredVersion` to return a string representation of the version constraint. This was broken with the recent introduction of `requiredVersion`, where `preferredVersion` only returned a value when explicitly set with `prefers(version)`. This change restores the previous functionality: a `requires` version constraint implies a `prefers` constraint, and a `strictly` constraint implies a `requires` constraint.
-
-
… 18 more files in
changeset.
Tuesday 24 Jul 2018
Separate 'prefer' and 'require' in dependency versions When we introduced the ability to declare a 'preferred' version on a dependency declaration, this was implemented such that declaring a "required" dependency version using `org:foo:1.0` was effectively the same as declaring a "preferred" version `org:foo { prefer '1.0' }`. In order to differentiate between the behaviour of required and preferred dependency versions, this commit introduces a separate model for these constraint types. This model is published to Gradle `.module` metadata files, and is retained internally throughout dependency resolution. At this stage, the behaviour of required and preferred versions is identical. A later commit will introduce the behavioural difference.
-
-
… 36 more files in
changeset.
Simplify construction of DefaultMutableVersionConstraint
-
-
… 6 more files in
changeset.
Saturday 21 Jul 2018
Retain separate versions for 'strictly' and 'prefers' Previously, a `strictly` version constraint was translated into a separate 'prefer' and 'reject' constraint: this is how it was processed internally, as well as how it was represented in a `.module` file. With this change, strict version constraints are logically retained as a first class version constraint: - `.module` files can have versions declared with `strictly` - Strict constraints are only translated to a reject version selector as part of resolution (not when parsing the constraint)
-
-
… 25 more files in
changeset.
Wednesday 29 Nov 2017
Ensure MutableVersionConstraint does not have null preferredVersion While the interface for `VersionConstraint` declared that version was `@Nullable`, in reality we prevented this when constructing an immutable version constraint. This meant that `MutableVersionConstraint.asImmutable()` converted null values to empty strings. This changes the contract so that `VersionConstraint.preferredVersion` is no longer `@Nullable`, and an empty string is consistently used to define a 'missing' preferred version, for all implementations of `VersionConstraint`.
-
-
… 6 more files in
changeset.
Tuesday 07 Nov 2017
Add code coverage for `DefaultImmutableVersionConstraint` Issue #3305
-
-
… 1 more file in
changeset.
|
