sbt-buildinfo v0.10.0 Release Notes

Release Date: 2020-08-09 // over 3 years ago
  • ๐Ÿ’ฅ Breaking change: scala.collection.immutable.Seq

    sbt-buidinfo 0.10.0 will generate scala.collection.immutable.Seq(...) instead of scala.collection.Seq(...).

    ๐Ÿ— This was contributed as #150 by @smarter.

    ๐Ÿ’ฅ Breaking change: output local time

    ๐Ÿ— sbt-buildinfo 0.10.0 will output build time in local time (using JSR-310 java.time.Instant) with timezone string.

    buildInfoOptions += BuildInfoOption.BuildTime
    

    ๐Ÿ— This was contributed as #156/#157 by @xerial and @leviramsey

    ๐Ÿ— BuildInfoOption.PackagePrivate

    buildInfoOptions += BuildInfoOption.PackagePrivate
    

    ๐Ÿ— sbt-buidinfo 0.10.0 adds a new option to make BuildInfo package private. This was contributed as #151 by @pcejrowski.

    ๐Ÿ— BuildInfoOption.ConstantValue

    buildInfoOptions ++= Seq(BuildInfoOption.ConstantValue, BuildInfoOption.PackagePrivate)
    

    ๐Ÿ— sbt-buidinfo 0.10.0 adds a new option to make BuildInfo fields constant value definitions when possible.

    package helloimport scala.Predef.\_private[hello] case object BuildInfo {/\*\* The value is "helloworld". \*/final val name = "helloworld"/\*\* The value is "0.1". \*/final val version = "0.1" .... }
    

    ๐Ÿ— We recommend making BuildInfo package private if you use this option. #164 by @eed3si9n

    ๐Ÿ› bug fixes and updates


Previous changes from v0.9.0

  • ๐Ÿ— sbt-buildinfo 0.9.0 is published for sbt 1.

    ๐Ÿ— TaskKey to BuildInfoKey conversion potentially breaking semantic change

    TL;DR No need for BuildInfoKey.of(...) or BuildInfoKey.ofN(...) any more. Use BuildInfoKey.outOfGraphUnsafe if your build definition is now circular.

    ๐Ÿ— sbt-buildinfo 0.8.0 deprecated the original TaskKey[A] to BuildInfoKey.Entry[A] implicit and explicit conversions (BuildInfoKey.task and BuildInfoKey.apply respectively), that executed the underlying sbt Task out of sbt's task graph execution, in favour of a newly introduced BuildInfoKey.of(...) and BuildInfoKey.ofN(...) API, which correctly wired up the task graph. See #114.

    ๐Ÿš€ As it was implemented (and released) it interacted poorly with sbt-buildinfo's BuildInfoKey.map API (#117), due to a mistake in the implementation and test coverage.

    ๐Ÿ— In resolving the issue it became clear that instead of introducing a new API, that required sbt-buildinfo users to change their source code to use, the already used conversions could have been modified to use the new Task-based semantics.

    ๐Ÿ— However, this change breaks any build definition that declares as a build info key any TaskKey that depends on sourceGenerators or resourceGenerators, because the build definiton would now be circular and fail to load. To fix this breaking semantic change the user has to either drop the key used, choose another key, or fallback to the previous semantics by using the not-deprecated BuildInfoKey.outOfGraphUnsafe API, also introduced in sbt-buildinfo 0.8.0.

    ๐Ÿ— #117/#119 by @dwijnand

    โž• Add direct support for sbt's Attributed

    ๐Ÿ— A number of keys defined by sbt use sbt's Attributed type, specifically the keys that define classpaths. Prior to this change defining any of these keys as a build info key would generate Seq[String] as Attributed would be simply converted to string with toString. sbt-buildinfo 0.9.0 introduces direct support for these keys so they generate Seq[File] instead.

    ๐Ÿ— #112/#120 by @dwijnand

    ๐Ÿ‘‰ Make toJson more JSONish

    ๐Ÿ— sbt-buildinfo is able to generate toJson method using the following setting:

    buildInfoOptions += BuildInfoOption.ToJson
    

    ๐Ÿ— sbt-buildinfo 0.9.0 makes the JSON encoding more natural:

    "libraryDependencies" :
      [ "org.scala-lang:scala-library:2.12.4",
        "com.lihaoyi:acyclic:0.1.7:plugin->default(compile)",
        .....]
    

    ๐Ÿ— #123 by @tonicebrian

    Do not generate multi-parameter infix calls

    ๐Ÿšš Multi-parameter infix calls may be removed in the future, so it's better not to generate this kind of code.

    ๐Ÿ— #124 by @Duhemm