Early semver labels are wrongly added

[dpevunov-cp]

I suppose that in some cases 'early-semver-<major/minor/patch>' are wrongly added to the PRs produced by scala-steward
Currently there is a code below to define the severity of change for early-semver. Judging by the definition I would say it should return None if major is not zero which in turn will lead to earlySemVerLabel not having 'early-semver-<major/minor/patch>' for dependency changes with major > 0

I have found that even in your test the label is wrongly added for the following dependency changes

val update1 = ("ch.qos.logback".g % "logback-classic".a % "1.2.0" %> "1.2.3").single
val update2 = ("com.example".g % "foo".a % "1.0.0" %> "2.0.0").single
val update = Update.Grouped("my-group", None, List(update1, update2))

val earlySemVerLabel = semVerVersions.flatMap { case (curr, next) =>
        SemVer.getChangeEarly(curr, next).map(c => s"early-semver-${c.render}")
      }

@tailrec
  def getChangeEarly(from: SemVer, to: SemVer): Option[Change] = {
    val zero = "0"
    // Codacy doesn't allow using `if`s, so using `match` instead
    (from.major === zero, to.major === zero) match { // work around Codacy's "Consider using case matching instead of else if blocks"
      case (true, true)
          if from.minor =!= zero ||
            to.minor =!= zero ||
            from.patch =!= zero ||
            to.patch =!= zero =>
        getChangeEarly(
          from.copy(major = from.minor, minor = from.patch, patch = zero),
          to.copy(major = to.minor, minor = to.patch, patch = zero)
        )
      case _ =>
        getChangeSpec(from, to)
    }
  }

[dpevunov-cp]

Could any maintainer review my finding and prove or reject it?

[mzuehlke]

To my understanding "Early SemVer" only adds additional rules in case the major version number is ZERO.
In case the major version is already greater then 1 the rules of "classic" SemVer apply.

See: Early SemVer and sbt-version-policy

When the major version is 0, a minor version increment MAY contain both source and binary breakages, but a patch version increment MUST remain binary compatible.

[dpevunov-cp]

To my understanding "Early SemVer" only adds additional rules in case the major version number is ZERO.
In case the major version is already greater then 1 the rules of "classic" SemVer apply.

I agree. But why for the case

val update1 = ("ch.qos.logback".g % "logback-classic".a % "1.2.0" %> "1.2.3").single
val update2 = ("com.example".g % "foo".a % "1.0.0" %> "2.0.0").single
val update = Update.Grouped("my-group", None, List(update1, update2))

we get these labels?
labels: library-update, early-semver-patch, semver-spec-patch, early-semver-major, semver-spec-major, commit-count:0

there is no early semver in libs versions or do I miss smth?

[dpevunov-cp]

@mzuehlke could you take a look please?

[mzuehlke]

I read the labels the following way:

• update1
  • if semver: semver-spec-patch
  • if early-semver: early-semver-patch
• update 2:
  • if semver: semver-spec-major
  • if early-semver: early-semver-major

As we don't know what policy the libraries are following we add labels for both specs.

[dpevunov-cp]

As we don't know what policy the libraries are following we add labels for both specs.

So that is not decided based on the MAJOR being zero or non-zero? Then it totally explains this issue. I thought early-semver is determined simply by MAJOR, am I wrong, @mzuehlke ?

[dpevunov-cp]

As we don't know what policy the libraries are following we add labels for both specs.

So that is not decided based on the MAJOR being zero or non-zero? Then it totally explains this issue. I thought early-semver is determined simply by MAJOR, am I wrong, @mzuehlke ?

@mzuehlke Could I have your reply here please?