I haven't checked Gradle 9.0, but I hope a lot that the

Project::version

not only becomes

Property

, but it becomes

Property<GradleVersion>

instead of

Property<String>

. And

GradleVersion

providing nice APIs for ordering, being able to check if a version is valid without catching exceptions, and so on. I think it is a common pattern used by multiple open-source semver plugins that have their own internal implementations of GradleVersion, but in the end, all companies of all sizes would benefit from this too.

Agree that

Property

would be helpful. Its doubtful that

GradleVersion

would happen - there are so many variations on what Gradle users use for versions, wouldn’t be practical to have a one-size-fits-all.

I know that, but that is indeed a problem, Gradle and automatic plugins like Dependabot or Renovate will use the Gradle one, so even if a library uses its own implementation, I think being forced to map the custom implementation to the official

GradleVersion

would help those libraries to catch errors with ordering and others.

Keep in mind those are two different conceptual versions - a version used for a “published library” has to reasonably conform to the ecosystem expectations - fit into Maven, be consumable by clients, usable by Dependabot/Renovate, etc. Other uses of version, such as an “application” are more of a closed-loop and may vary based on user needs. Perhaps the former could be cleaned up/standardized.

You are right, but do you think

GradleVersion

is not enough flexible? I haven't checked it deeply, but I think it would fit SemVer and Calendar versioning which would the two most used approaches. Anyway, I think the

Project::version

is highly coupled to the fact it is done for Maven, so limiting it wouldn't be a problem and other plugins could do what Android Gradle Plugin does, that is having its own versioning inside its extension.

Haven’t look at the specifics of GradleVersion; it seems challenging to support a bunch of variations, where the format, ordering are different. A Maven version isn’t quite the same as SemVer (there are subtle diferences in sorting), and so on.

Yeah, but that is the problem it would fix, I have my own plugin, but there are a lot of them, and they are used to publish to Maven, so if they are not mapping correctly, they are allowing wrong things.

That’s fine for the case of publishing a library inside the Maven ecosystem, there’s a defined version scheme there. Have a lot of cases where artifacts are published elsewhere using SemVer, which isn’t the same thing as Maven, but is the “project version”.

I follow you and it would be analyzed in more detail. I know Gradle can be used for Swift, but I don't know if it supports dependencies, and if it does and it still follows the Gradle docs ordering, then for sure it should be forced to be a

GradleVersion

. I have checked the Swift docs but it is not adding external dependencies... I will look for more samples