#semver anyone? Semantic versioning like
3.14.1 as major.minor.patch
is defined on https://semver.org/ with
PATCH version when you make backward compatible bug fixes
What is a "backward compatible bug fix"? After a bug fix, the software is no longer compatible with the buggy version, ON PURPOSE. Any dependent software which accommodates so far to the bug may now have problems?
What am I missing?
Finally finished that SemVer rant. Say no to ZeroVer: https://blog.nytsoi.net/2026/04/03/say-no-to-zero-ver/
Was that change really a patch—or did you just break someone’s build? Manual #SemVer is fragile, especially in growing teams. @JagoVreede enforces it with code.
Make your versions trustworthy again and avoid hidden breaking changes: https://javapro.io/2026/03/26/semantic-versioning-done-automatically/
I also fixed the rustdoc bug upstream!
https://github.com/rust-lang/rust/pull/153465/
Attributes like #[doc(test(attr(deny(rust_2018_idioms))))] are accidentally emitted without the final ]. Also, the #[doc(test(no_crate_inject))] attribute is mistakenly emitted as #[doc(no_crate_in...
cargo-semver-checks v0.47 is live now ✨
Inside, you'll find:
- a workaround for a Rust 1.94 rustdoc bug that caused crashes in some projects
- 7 new lints
Happy SemVer Sunday!
https://github.com/obi1kenobi/cargo-semver-checks/releases/tag/v0.47.0
#SemVer! #DateVer! #MonotonicVer!
There are lots of #options, so following rule 927, I hereby propose my own #alternative.
v. 1
v. j1
v. -1
v. -j1
v. 2
v. j2
[...]
One problem is that minor releases require doing #trigonometry.
#XKCD927 #standards #versioning #mathematics #complex #ComplexNumbers #engineering #trigonometry #sin #cosin
Blogged : update semantic version using #bash script
https://blog.revathskumar.com/2026/02/update-semantic-version-using-bash-script.html
For all of my JavaScript projects, I depend on the npm version command to update the version number for generating a release. So when I wanted to release my Zig project (clipz), I was looking for something similar to update the version number in the build.zig.zon file. Since Zig doesn’t have any command equivalent to npm version, I decided to go with a simple shell script.
Handling Breaking Changes in a Design System Without Causing Chaos, by @shaunbent (@zeroheight):
https://zeroheight.com/blog/handling-breaking-changes-in-a-design-system-without-causing-chaos/
I realize that I might have misused the "semantic versioning" with the last release of Back In Time.
Compared to 1.5.6, there are so many breaking changes in 1.6.0, that it better should have been 2.0.0.
What do you think?
Harald
Nicd
JAVAPRO
Predrag Gruevski
C.
Revath S Kumar 
Frontend Dogma
edburns
Back In Time