Controversial opinion: what a waste of attention. We should have a declared range of versions (we attest) our libraries support, and separately a freeze file for reproducible test running (and other code executions, like runMain, console, what have you).https://twitter.com/fst9000/status/1227149976196845569 …
I'm also against the idea of build files living in git repositories. It means you can't update the build (e.g with new dependencies) without changing the repo.
-
-
Instead, I want a file in the repo which points to the repeatable build which was known to work for that version of the code, but which can be trivially updated to the latest version published post-hoc which claims to be backwards compatible with that version.
-
So you want to replicate Git's immutable Merkel Tree machinery… but in another tool that isn't git? Like I think I kinda see what you're getting at, but it's really just another variant of a "middleground" proposal towards removing persistence.
End of conversation
New conversation -
-
-
Distributables should always be a pure function of two things: 1) a repository git hash, and 2) an append-only Merkle Tree representing third-party publication state. This is why having the build be part of the repo is so important.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.