> Imagine you voluntarily made your build non-reproducible by making them depend on time

> No; in fact it's perfectly reasonable, and at the core of what the author doesn't seem to get. Developers have motivations other than reproducibility. The entire reason we have version number schemes like this is so that we can improve our code while also advertising reasonable expectations about compatibility. If we have dependents, then hopefully this also improves their UX indirectly — whether by taking advantage of optimizations we made, not encountering bugs that were actually our fault, etc. Similarly, if we have dependencies, we can seek to take advantage of that. I'm actually with the author on this one, but checking-in your lockfile to version-control gets you this.

> No; in fact it's perfectly reasonable, And this is how I once ended spending a Friday evening in a frantic hurry because a dependency decided to drop support for "old" language versions (that is, all except the two newest ones) in its patch-version level update. And by "drop support" I mean "explicitly forbid from building with language versions less than this one". > The entire reason we have version number schemes like this is so that we can improve our code while also advertising reasonable expectations about compatibility. Except, of course, some library authors deliberately break semver because they just hate it, see e.g. quote in [0], slightly down the page. [0] https://dmytro.sh/blog/on-breaking-changes-in-transitive-dep...