Use `-bin-` version suffix to convey binary version to sbt in nightly/PR-validation-snapshot builds #252

adriaanm · 2016-10-26T01:03:54Z

As suggested by @dwijnand. Sbt logic: https://github.com/sbt/sbt/blob/v0.13.12/util/cross/src/main/input_sources/CrossVersionUtil.scala#L42

ensure we're on sbt >= 0.13.12

I've started looking for spots that need to be updated (using git grep nightly -- need to do same for PR validation sha versioning)

changes in scala/scala:

README.md:231:Note that we currently don't publish nightly (or SNAPSHOT) builds in maven or ivy
project/VersionUtil.scala:51:    * ("2.11.8", "SHA-NIGHTLY" ) -> ("2.11.8-7559aed-nightly",         "2.11.8-7559aed-nightly",  "2.11.8.v20151215-133023-NIGHTLY-7559aed")
project/VersionUtil.scala:58:    * job uses "SHA-SNAPSHOT". A proper version number for a nightly build can be computed with "SHA-nightly". An empty
project/VersionUtil.scala:86:      case "SHA-NIGHTLY"  => (s"$base-$sha-nightly", s"-$sha-nightly",  s"$base.v$date-NIGHTLY-$sha", true)
scripts/jobs/integrate/bootstrap:26:# - Otherwise, a nightly release is built:
scripts/jobs/integrate/bootstrap:27:#    - version number is read from the build.number file, extended with -$sha-nightly
scripts/jobs/integrate/bootstrap:36:#  - Otherwise (moduleVersioning has some other value): in this mode we use nightly version numbers for modules.
scripts/jobs/integrate/bootstrap:38:#    - The <MODULE>_VER is set to a nightly version, for example "1.0.3-7-g14888a2-nightly" (you can't override <MODULE>_VER)
scripts/jobs/integrate/bootstrap:299:  #  - the patch version is > 0     : 2.12.1-M1, 1.12.3-RC2, 2.12.1-sha-nightly, 2.12.2-SNAPSHOT
scripts/jobs/integrate/bootstrap:301:  # Otherwise, the binary version is the full version: 2.12.0-M1, 2.12.0-RC2, 2.12.0-sha-nightly, 2.12.0-SNAPSHOT
scripts/jobs/integrate/bootstrap:305:  # Note: during the pre-release cycle of a major release (e.g. before 2.12.0), the SCALA_BINARY_VER of nightly / SNAPSHOT
scripts/jobs/integrate/bootstrap:306:  # versions is the full version, e.g. 2.12.0-sha-nightly, so modules are always re-built. This is in line with what sbt
scripts/jobs/integrate/bootstrap:308:  # Once the 2.12.0 release is out, the binary version is 2.12 for all versions (e.g. for 2.12.1-sha-nightly).
scripts/jobs/integrate/bootstrap:331:      echo "No tag found, building nightly snapshot."
scripts/jobs/integrate/bootstrap:338:      # TODO: publish nightly snapshot using this script - currently it's a separate jenkins job still running at EPFL.
scripts/jobs/integrate/bootstrap:373:  echo "$(git describe --tag --match=v* | cut -dv -f2)-nightly"
scripts/jobs/integrate/bootstrap:378:  echo "$(git describe --tag | cut -dv -f2)-nightly"
scripts/jobs/integrate/bootstrap:473:      STARR_VER_SUFFIX="-$(git rev-parse --short $STARR_REF)-nightly"

changes in scala/scala-dist:

scripts/jobs/release/website/archives:11:if [[ "$version" =~ .*-nightly ]]
scripts/jobs/release/website/archives:12:then archivesDir="~linuxsoft/archives/scala/nightly/2.11.x"
scripts/jobs/release/website/update-api:9:if [[ "$version" =~ .*-nightly ]]
scripts/jobs/release/website/update-api:10:then archivesDir="~linuxsoft/archives/scala/nightly/2.11.x"

no changes in scala/scala-dist-smoketest
changes in scala/scala-jenkins-infra:

templates/default/jobs/scala/integrate/bootstrap.xml.erb:23:     :desc => "Specifying this parameter will cause a release to be built. If it&apos;s empty (and HEAD does not have a tag that parses as a version), a -nightly release is built."},
templates/default/jobs/scala/integrate/main.xml.erb:14:      {:name => "SCALA_VER_BASE",       :desc => "[For bootstrap] Specifying this parameter will cause a release to be built. If it&apos;s empty (and HEAD does not have a tag that parses as a version), a -nightly release is built."},
templates/default/jobs/scala/release/website/archives.xml.erb:13:    <p>When version ends in -nightly, the root for the expansion process

The text was updated successfully, but these errors were encountered:

dwijnand · 2016-11-02T14:02:30Z

Switching this removes the need for instructing to run set every scalaBinaryVersion := "2.12", eg. scalamacros/paradise#88

SethTisue · 2016-12-08T23:28:06Z

this is an ongoing source of pain for Scala community build work

milessabin · 2016-12-11T20:44:49Z

You'll find CrossVersion.patch (new on 0.13.13) helpful for plugins (eg. macro-paradise).

dwijnand · 2017-03-08T21:56:19Z

@lrytz Are you taking care of the checklist here?

SethTisue · 2017-03-08T22:01:48Z

I updated http://stackoverflow.com/a/40622879/86485 and notified scala/contributors

milessabin · 2017-03-09T07:57:37Z

See also typelevel/scala#135 ... to support compiler plugins you'll want to use CrossVersion.patch, and while you're at it you might as well use scalaOgranization.value to get Typelevel Scala compatibility too.

lrytz · 2017-03-09T10:20:14Z

Is there any documentation / discussion on CrossVersion.patch? I only found the release notes (https://github.com/sbt/sbt/releases/tag/v0.13.13).

I don't see how it makes sense to use it for compiler plugins. If I build a compiler plugin with a Scala version 2.12.2-bin-abc123 (which is a version before the release of 2.12.2), then the binary version will be 2.12.1. However, any commit to scala/scala between revision abc123 and the final 2.12.2 may break binary compatibility. A plugin built with 2.12.2-bin-abc123 can only safely be used with 2.12.2-bin-abc123, not any other version.

dwijnand · 2017-03-09T16:30:02Z

Sorry, those release notes should've linked to the PR that introduced the feature: sbt/sbt#2757, and also the docs should've included a description..

The motivating use case is Typelevel Scala.

Typelevel would like to be able to make additional releases - e.g a release between 2.12.1 and 2.12.2, 2.12.1-bin-typelevel-20170309, which is Typelevel Scala 2.12.1 + more patches and is backwards binary compatible to Scala 2.12.1.

At the same time they would like to make switching to (or testing out) Typelevel Scala not require modifying the build files. This is possible by sbt because you can simply create new files (git ignored), e.g local.sbt.

These two requirements break down when it comes to compiler plugins as historically they've been defined as:

compilerPlugin("org.scalamacros" %% "paradise" % "2.1.0" cross CrossVersion.full)

And that means switch to 2.12.1-bin-typelevel-20170309 would break your build: there is no paradise_2.12.1-bin-typelevel-20170309-2.1.0.jar.

But switching that to:

compilerPlugin("org.scalamacros" %% "paradise" % "2.1.0" cross CrossVersion.patch)

means that the -bin-.. suffix is stripped and the same old paradise_2.12.1-2.1.0.jar is used.

dwijnand · 2017-03-09T16:30:43Z

Anyways, WRT this issue I see you've knocked out all the checkpoints, so I guess we can close it now?

lrytz · 2017-03-09T20:07:19Z

Thanks, Dale! Would be nice to add some of that to http://www.scala-sbt.org/0.13/docs/Cross-Build.html.

SethTisue mentioned this issue Dec 8, 2016

regression: ScalaMock failing, fails to use Scala-version-specific source directory scala/community-build#434

Closed

adriaanm mentioned this issue Feb 23, 2017

New repository for benchmark builds scala/scala-jenkins-infra#222

Open

lrytz mentioned this issue Mar 6, 2017

new version numbers for snapshot and integration builds, new repository scala/scala#5757

Merged

lrytz closed this as completed Mar 9, 2017

dwijnand mentioned this issue Mar 9, 2017

Document CrossVersion.patch sbt/website#333

Closed

dwijnand mentioned this issue May 19, 2017

Switch projects which use CrossVersion.full/"org.scala-lang" to CrossVersion.patch/scalaOrganization.value typelevel/scala#135

Open

35 tasks

dwijnand mentioned this issue May 1, 2018

Drop -SNAPSHOT from the version number of published PR builds #495

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use `-bin-` version suffix to convey binary version to sbt in nightly/PR-validation-snapshot builds #252

Use `-bin-` version suffix to convey binary version to sbt in nightly/PR-validation-snapshot builds #252

adriaanm commented Oct 26, 2016 •

edited by lrytz

Loading

dwijnand commented Nov 2, 2016

SethTisue commented Dec 8, 2016 •

edited

Loading

milessabin commented Dec 11, 2016 •

edited

Loading

dwijnand commented Mar 8, 2017

SethTisue commented Mar 8, 2017

milessabin commented Mar 9, 2017

lrytz commented Mar 9, 2017

dwijnand commented Mar 9, 2017 •

edited

Loading

dwijnand commented Mar 9, 2017

lrytz commented Mar 9, 2017

Use -bin- version suffix to convey binary version to sbt in nightly/PR-validation-snapshot builds #252

Use -bin- version suffix to convey binary version to sbt in nightly/PR-validation-snapshot builds #252

Comments

adriaanm commented Oct 26, 2016 • edited by lrytz Loading

dwijnand commented Nov 2, 2016

SethTisue commented Dec 8, 2016 • edited Loading

milessabin commented Dec 11, 2016 • edited Loading

dwijnand commented Mar 8, 2017

SethTisue commented Mar 8, 2017

milessabin commented Mar 9, 2017

lrytz commented Mar 9, 2017

dwijnand commented Mar 9, 2017 • edited Loading

dwijnand commented Mar 9, 2017

lrytz commented Mar 9, 2017

Use `-bin-` version suffix to convey binary version to sbt in nightly/PR-validation-snapshot builds #252

Use `-bin-` version suffix to convey binary version to sbt in nightly/PR-validation-snapshot builds #252

adriaanm commented Oct 26, 2016 •

edited by lrytz

Loading

SethTisue commented Dec 8, 2016 •

edited

Loading

milessabin commented Dec 11, 2016 •

edited

Loading

dwijnand commented Mar 9, 2017 •

edited

Loading