The knock-on breaking changes caused by the Property.set(null) change - intentional or regression?


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:

An earlier change in Gradle 5.1 deprecated fields like version in AbstractArchiveTask in favour of archiveVersion which uses Property<String> rather than String: 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:

The above was recommended in the shadowJar documentation: 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 as Property so users would not expect a change to Property to affect these fields.
  • The fact that version inherits the behaviour of Property 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.)