Semver is based on a lie. It assumes that you can define what is the proper behavior of a library. That's
not necessarily true, and can be subtlety false, and different depending on the use case. I can think on some situations where I trusted semantic versioning and it bited me when an update was made. I am not talking about new bug introductions. I assumed behavoir that the library owner assumed as not important.
Yes, no matter how hard you try semver will sometimes get it wrong, but as long as it usually doesn't it's still useful to let my tools do their best at automatically selecting a version of the library that will be compatible with every part of my application that cares, and that has had as many bugs fixed as possible. That's what semver allows cargo to do, and 99.9% of the time it just works. 0.1% of the time you have to manually intervene, and that's ok. It's better than having to manually intervene 100% of the time, or the old-school C solution of "just pick whatever is lying around on the OS and hope it works/is compatible".
In the end it's why Google insists on "vendoring" (checking in) third party dependencies and only having one version of a dependency for the entire (massive) mono repo and designated maintainers. You want a new version? Put a ring on it. Test it, and maintain it.
At first I thought it was insanity. Now, buried in a maze of transitive third party and first party dependencies scattered across multiple git repositories and crates, I really really miss it.
Of course like many other things there it depends on having lots of well-paid staff, without deadline guns to their head, committed to code quality and infrastructure.
Because it’s not perfect doesn’t mean it’s useless. If semver correctly describes 90% of behaviour changes (random number), that’s a significant load off my plate as a lib user
There should be no shame in younger people above ourselves. I am 46 and a coupple of years ago the CEO and CTO of the company I worked for were in their twenties. It did not bother me at all. If they do their jobs properly, it is fine at any age. If they dont do their jobs properly, it is not fine at any age.
I think that there are 2 foundationañ problems that make complex projects over budget:
1. Stakeholders are incentivized to negotiate down the budget, skewing the result.
2. Breaking down a big task into smaller ones comes with the risk of missing some activities, but adding a nob-required subtask is almost imposible, also skewing the results.
Estimates of big endevours must be made by comparison instead of breaking down the tasks to avoid the second issue. That's one of the little secrets that make poker planning succesfull.
Extra points: leave old and outdated documentation and scripts in the repository. New documentation should go to a wiki that is not referenced in code and does not track versions. Different parts of the wiki should apply to different code versions.
I think that the parent says that while you can learn almost anything from youtube, it is imposible for other people to know that you know something you learned on youtube without a test.
Funny enough, it's impossible for people to know what you've learned and retained at University without a test. They're more willing to assume that you have though.
I find it sad that this post was flagged. If it is not found interesting by the community no one would upvote it and it would just fade away. Flagging posts like this one makes hacker news far less interesting.
