Drop -SNAPSHOT from the version number of published PR builds

[dwijnand]

Quoting from https://github.com/scala/scala/blob/v2.13.0-M3/README.md#scala-ci:

CI performs a full bootstrap. The first task, validate-publish-core, publishes a build of your commit to the temporary repository https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots/. Note that this build is not yet bootstrapped, its bytecode is built using the current starr. The version number is 2.12.2-bin-abcd123-SNAPSHOT where abcd123 is the commit hash. For binary incompatible builds, the version number is 2.13.0-pre-abcd123-SNAPSHOT.

As the version number uses the git HEAD SHA I see no reason to demarcate it as unstable with -SNAPSHOT. I propose the suffix is dropped.

I believe #252 and scala/scala#5757 are good places to start looking; for how things are done, perhaps why they were done that way, and whom to ping for more info.. 😄

[SethTisue]

I agree. And iirc, @szeiger has also proposed this change.

[jvican]

If this happens, then the following needs to be changed in scala.util.Properties:

  val developmentVersion =
    for {
      v <- scalaPropOrNone("maven.version.number")
      if v endsWith "-SNAPSHOT"
      ov <- scalaPropOrNone("version.number")
    } yield ov

[SethTisue]

and @milessabin points out this -SNAPSHOT checking code in the compiler-benchmark project: https://github.com/scala/compiler-benchmark/blob/master/build.sbt#L28-L33

[retronym]

One use case for leaving -SNAPSHOT is when the working directory has some uncommited changes. I don't always remember to add/amend a temp commit when doing a publishLocal and trying that commit in some other SBT project.

IIRC some parts of the SBT or Zinc build has version number logic based on git status.

[retronym]

The (big) advantage of removing -SNAPSHOT is worth stating explicitly: resolving the build is faster in downstream projects, SBT won't look for an updated version on remote resolvers when one is found locally.

[jvican]

One use case for leaving -SNAPSHOT is when the working directory has some uncommited changes. I don't always remember to add/amend a temp commit when doing a publishLocal and trying that commit in some other SBT project.

I think the build logic could be modified to detect that the CI is publishing the version, and therefore the -SNAPSHOT suffix can be removed.

[szeiger]

Indeed, there's no reason we can't have both. CI builds already use commands to set up the build for the current stage (like setupPublishCore). We can have a -SNAPSHOT version be the default and switch to a non-snapshot version in CI.

[dwijnand]

Given it's fairly simple to verify if the working directory has uncommitted changes, why not just use that?

[szeiger]

You can take it a step further and compute a sha from the uncommitted changes. I considered this option when doing the switch from ant to sbt. Both have the problem that they ignore broken incremental builds, deliberately broken incremental builds ("ant style"), accidental builds from the wrong build definition, etc.

[dwijnand]

I don't understand the problems.

[SethTisue]

this should wait until #507 is complete

[dwijnand]

Why?

[SethTisue]

Why?

well, I have to reconstruct what I might have been thinking last May

we'd rather do the publishing from Travis than Jenkins (since the long term goal is to decrease/eliminate our reliance on Jenkins, because maintaining our own Jenkins instance is a drag), and if publishing is moving, it makes sense to do changes (like this -SNAPSHOT thing) on the new setup rather than having to port them from the old setup to the new, and also so that any disruption for users only happen once

otoh,

• the move to Travis is happening very sloooooowly, no progress lately
• idk but perhaps the -SNAPSHOT change is so easy that it would be just fine to make it on Jenkins

[olafurpg]

FWIW, -SNAPSHOT artifacts publish more reliably in my experience compared to non-SNAPSHOT. The sonatypeClose step for non-SNAPSHOT releases frequently times out in my projects, especially around ~4-5pm CET when people are working in both Europe and the US. I don't think that has ever happened for me with -SNAPSHOT releases.

[dwijnand]

We publish to our own repo. Though we could change that too.