Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dwijnand opened this issue May 1, 2018 · 17 comments
Closed

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

dwijnand opened this issue May 1, 2018 · 17 comments

Comments

@dwijnand
Copy link
Member

dwijnand commented May 1, 2018

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
Copy link
Member

SethTisue commented May 1, 2018

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

@jvican
Copy link
Member

jvican commented May 1, 2018

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
Copy link
Member

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
Copy link
Member

retronym commented May 2, 2018

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
Copy link
Member

retronym commented May 2, 2018

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
Copy link
Member

jvican commented May 3, 2018

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
Copy link

szeiger commented May 3, 2018

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
Copy link
Member Author

dwijnand commented May 4, 2018

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

@szeiger
Copy link

szeiger commented May 4, 2018

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
Copy link
Member Author

dwijnand commented May 4, 2018

I don't understand the problems.

@SethTisue
Copy link
Member

this should wait until #507 is complete

@dwijnand
Copy link
Member Author

dwijnand commented Feb 2, 2019

Why?

@SethTisue
Copy link
Member

SethTisue commented Feb 4, 2019

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
Copy link

olafurpg commented Feb 5, 2019

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
Copy link
Member Author

dwijnand commented Feb 5, 2019

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

@dwijnand
Copy link
Member Author

dwijnand commented Nov 4, 2020

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.

Still a good idea. But we haven't (IMO) sweated this penalty so let's "leave well enough alone".

@dwijnand dwijnand closed this as completed Nov 4, 2020
@SethTisue
Copy link
Member

Yeah, I mean if someone really wants to make this change I wouldn't stand in their way, but I don't think we need an indefinitely-open ticket on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants