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

Convenience for turning off the timestamp #123

Open
jroper opened this issue Sep 6, 2019 · 6 comments
Open

Convenience for turning off the timestamp #123

jroper opened this issue Sep 6, 2019 · 6 comments

Comments

@jroper
Copy link
Member

jroper commented Sep 6, 2019

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

dwijnand commented Sep 6, 2019

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

raboof commented Sep 6, 2019

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

jroper commented Sep 6, 2019

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.

@dwijnand
Copy link
Member

dwijnand commented Sep 6, 2019

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

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?

@dwijnand
Copy link
Member

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

I agree that use-case should be fixed.

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

4 participants