Add "versionScheme" labels to pull-requests.

[mzuehlke]

An additional label is added that reflect the versionScheme of the updated artifact. This is a new label. The existing labels have not been changed to ensure compatibility.

• versionSchemereference: https://www.scala-sbt.org/1.x/docs/Publishing.html#Version+scheme
• As suggested in Show release notes URL from POM in PR body #2863 (comment) getting the data was trivial.

fixes #2541

[codecov]

Codecov Report

Base: 90.63% // Head: 90.65% // Increases project coverage by +0.01% 🎉

Coverage data is based on head (77e035e) compared to base (d0929fe).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2925      +/-   ##
==========================================
+ Coverage   90.63%   90.65%   +0.01%     
==========================================
  Files         155      155              
  Lines        3064     3070       +6     
  Branches      221      216       -5     
==========================================
+ Hits         2777     2783       +6     
  Misses        287      287              

Impacted Files	Coverage Δ
...a/org/scalasteward/core/coursier/CoursierAlg.scala	96.15% <100.00%> (+0.07%)	⬆️
...calasteward/core/coursier/DependencyMetadata.scala	100.00% <100.00%> (ø)
...lasteward/core/forge/data/NewPullRequestData.scala	100.00% <100.00%> (ø)
...ala/org/scalasteward/core/nurture/NurtureAlg.scala	19.20% <100.00%> (+2.19%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[fthomas]

I like this! The only thing I would change is how the label is rendered. I would prefer version-scheme:$scheme over version-scheme-$scheme to make it clearer that $scheme is the value of the info.versionScheme property.

I'd also note that this label is purely informational in case of pvp with version numbers that have four or more components A.B.C.D. With such versions none of the other semver labels we currently have are present, so version-scheme:pvp would then be the only version related label. But if we look at that label we don't know if the bump is breaking (A.B is different), non-breaking (C is different), or other (D is different). I think this is fine for now, since we can extend this label in the future by appending a change identifier to it: version-scheme:pvp:non-breaking.

If we have the version-scheme label with the change identifier, maybe we can also deprecate and remove the other early-semver and semver-strict labels we currently have. For example, if there is no versionScheme defined but the version numbers have three components and both start with zeros, Scala Steward could add a version-scheme:early-semver-inferred:minor. It is inferred because Scala Steward inferred the scheme from the version numbers.

[mzuehlke]

I like this! The only thing I would change is how the label is rendered. I would prefer version-scheme:$scheme over version-scheme-$scheme to make it clearer that $scheme is the value of the info.versionScheme property.

Good suggestion, I adapted the label format.
And I like your ideas to enhance the new labels in the future 👍

/cc @julienrf (because you suggested the feature)

waiting changes

[fthomas]

@exoego Are you waiting for further changes or can we merge this?

[mzuehlke]

I first thought to roll your suggestion into this PR, but didn't found the time. Will merge the PR in it's current version.