sbt/sbt-dynver

Convenience for turning off the timestamp

jroper opened this issue · 6 comments

jroper commented

Sometimes when you're developing a library or sbt plugin, the most convenient way to test it is in another project, and so you have a dev cycle like this:

  1. Run sbt publishLocal
  2. Rerun command in the dependent project to test the changes

When using sbt-dynvar, this dev cycle becomes far more tedious:

  1. Run sbt publishLocal
  2. Copy the timestamp that was built
  3. Open plugins.sbt/build.sbt in dependent project
  4. Update dependency to have the new timestamp
  5. Rerun command in other project to test the changes

It'd be nice if out of the box, sbt dynver had a system property that could be set to turn off outputting the timestamp, perhaps replacing it with dev. Of course, I can do this in my own project, but often the project is not my own project, and I don't want to go updating the build.sbt of that project to override the sbt config, and then need to back it out each time I commit, etc.

dwijnand commented

I'd recommend redefining the version number to that end. So set ThisBuild / version := "2.3.0-dev". Alternatively I'd recommend adding the build into the dependant build. I'd happy to detail those in the README. Less so to introduce an easy flag to make sbt-dynver's versions unstable.

raboof commented

set ThisBuild / version := "2.3.0-dev"

(note that you can do this in your own version.sbt, it doesn't need to be in the projects' build.sbt)

jroper commented

But they're not stable with the timestamp in there either - if you run publishLocal twice from the same sbt session, it uses the same timestamp from when sbt started up, so you can have hundreds of different builds with the same version number. So allowing this would put us in a no different situation with regards to version stability. The reality is, as soon as you build a source tree that has local changes, all bets are off, you cannot reason at all about what is in the artifact. I don't think timestamps give any value there.

  • 👍1
dwijnand commented

While you're right that sadly the timestamps are staler than they should be they're still fresher than the effect of a dynverDirty := Some("-dev") coming from somewhere.

ThijsBroersen commented

I mostly remove the timestamp because it causes different snapshot version-names when crossbuilding for different scala versions. When switching scala-versions the version is recalculated and hence it can be different when crossbuilding. Is this solvable without removing the timestamp?

  • 👍2
dwijnand commented

I've worked around that by caching the first timestamp in system properties 🙂 ...

I agree that use-case should be fixed.

  • 👍2