3 ms·
As other people have said, I normally run unit tests after changing comments. It's part of my check-in routine. That said, I maintain close to a dozen Rust uti
by ekidd 3y ago
As other people have said, I normally run unit tests after changing comments. It's part of my check-in routine.
That said, I maintain close to a dozen Rust utilities, some of which only get updated every two or three years. And when I update them, I try to update all their dependencies. We're talking 250-400 transitive dependencies in most cases, and typically two years of evolution of all of them. In other words, this is a worst-case scenario for semver. I'm often looking at 600 "library-years" of supposedly compatible changes.
4 times out of 5, the "semver-compatible" updates work flawlessly. The 5th time, I'll occasionally run into a minor problem that takes me 20 minutes to clean up. Once every several years, I'll run into a genuine headache.
To me, this is stunningly successful. Rust semver isn't perfect, but it's a genuine joy from a maintenance perspective. And I expect things to get even better, thanks to tools like the one in the OP.
- cratermoon 3y ago> I normally run unit tests after changing comments. It's part of my check-in routine. I run the tests after running even a part of a file through the formatter. And no, I don't work in Python.
- kibwen 3y ago> I normally run unit tests after changing comments Thirded. Tests get run before I commit, period. The grandparent's apparent argument that semver has failed because you have to run tests when upgrading patch versions is utterly alien to me. Has any semver proponent ever claimed such a thing?