Stamp It! All Programs Must Report Their Version
secure
20 points
7 comments
April 05, 2026
Related Discussions
Found 5 related stories in 61.9ms across 3,663 title embeddings via pgvector HNSW
- DoesItAgeVerify: The age verification status of Open Source Operating Systems pkaeding · 48 pts · March 30, 2026 · 43% similar
- If It Quacks Like a Package Manager jandeboevrie · 54 pts · March 08, 2026 · 43% similar
- More on Version Control velmu · 66 pts · March 29, 2026 · 43% similar
- Apple randomly closes bug reports unless you "verify" the bug remains unfixed zdw · 343 pts · March 25, 2026 · 42% similar
- Reports of code's death are greatly exaggerated stevekrouse · 341 pts · March 22, 2026 · 40% similar
Discussion Highlights (5 comments)
ploution
The version seems to be the number one information in order to avoid making things worse! Not all solutions apply to all versions of a running product.
sgbeal
> --moreversion Suggestion: more conventional and intuitive would be: --version --verbose
bombcar
Stamps are nice, but git and friends miss something that the VCS of yore would give you - a monotonously increasing number you could stick somewhere in your version - and be able to tell at a glance which was newer. 2.4.16-12 vs 2.4.16-35 - obviously -35 is later. But 2.4.16-bcbd1c6 vs 2.4.16-d645104 - which is later? Compile dates won't necessarily help because "earlier" code could have been compiled later. It's forcing the versioning to do something it shouldn't, arguably, but is nice to have something that the user can decipher (even if you still should have the commit).
sourcegrift
Great post! I propose all programs have a `--version` flag. Anything similar for Rust + Cargo right now?
sourcegrift
Dang please mark this post for boosting?