Background
A breaking change introduced in Gradle 5.6 was a change to Property.set(null)
to instead use the default value (via convention) rather than “not defined”. The change was made here: https://github.com/gradle/gradle/pull/9776
An earlier change in Gradle 5.1 deprecated fields like version
in AbstractArchiveTask in favour of archiveVersion
which uses Property<String>
rather than String
: https://github.com/gradle/gradle/commit/5c458c522af58612f2bfa85568e07aa29e585931. Backwards compatibility was provided by mapping the old getters and setters to Property
's getter and setter.
The Problem
The 5.6 change has now meant the following now has changed behaviour:
jar {
version = null
}
This has caught people off-guard downstream. An example here is the shadowJar
plugin. Duplicate issues were raised in the days following the 5.6 release:
- https://github.com/johnrengelman/shadow/issues/508
- https://github.com/johnrengelman/shadow/issues/509
The above was recommended in the shadowJar
documentation: https://imperceptiblethoughts.com/shadow/configuration/#configuring-output-name. Setting the likes of version
to null was common in use of shadowJar
.
An unintentional consequence to an intentional change?
It’s clear that the 5.6 change is intentional. It is documented as a breaking change. It’s why I haven’t reported this directly as a regression.
However, I believe that the consequences of the change are unintentional. I believe this because:
- Fields like
version
are not documented asProperty
so users would not expect a change toProperty
to affect these fields. - The fact that
version
inherits the behaviour ofProperty
is an implementation detail - not an API one. - The purpose of
version
is purely for backwards compatibility. 5.6 breaks this single purpose in some cases.
Do the devs view this as a regression worth reporting or should I simply inform users to change their build files now, instead of when Gradle 6 releases?
(Note that version
is purely an example - there will be other fields/properties.)