search

stringbean / sbt-dependency-lock

sbt plugin for creating dependency lockfiles
https://stringbean.github.io/sbt-dependency-lock
Apache License 2.0
14 stars 6 forks source link

Remove the timestamp field #39

Open Prillan opened 1 year ago

Prillan commented 1 year ago

What are you suggesting?

A bit controversial perhaps, but I suggest removing the timestamp field from the lock files. It is a constant source of conflicts in pull requests, in particular when you have automated tooling that performs updates, like scala-steward or renovate.

Obviously, if you feel like the field serves a purpose, I'm happy to hear about that.

How will this benefit other users?

No more unnecessary conflicts. Parallel changes that touch different dependencies will have a higher chance of being conflict free.

Is there a workaround that can do this now?

Three, but all of them quite annoying:

  1. run dependencyLockWrite manually on conflicts, and (force) push changes
  2. run dependencyLockWrite in CI and push changes on conflicts
  3. cluster updates in the updater tools (this means you lose the ability to separate patch/minor/major updates)

None of them are very satisfactory. The first requires manual work on each conflict, the second adds a lot of complexity and the third removes important features from the tooling.

Will this require a lock file change?

Yes. But old lock files are readable by newer versions of the plugin. It's also possible to have a migration period, where the new version of the plugin keeps the timestamp intact. We can then set it up so that it removes the timestamp completely some time in the future.

stringbean commented 3 months ago

I think there is benefit in having the timestamp as it indicates at what point in time dependencies were updated and integrity hashes were taken. The timestamp does become a burden during merges for some scenarios though.

In the next lockfile version (v2) I'll make the timestamp optional (default enabled) and add a setting to control it.