Have you ever found something so tricky that you needed two weeks to get 200 lines of code exactly right?
The new cargo-semver-checks version had one of those cases. Here's why 
https://predr.ag/blog/when-is-trait-can-be-implemented-public-api/
cargo-semver-checks v0.40 is out
https://github.com/obi1kenobi/cargo-semver-checks/releases/tag/v0.40.0
Is it just me, or does Semantic Versioning feel more like a guideline than a strict rule in many open source projects? Breaking changes in patch versions, features in minor updates…
Suppose you're reading `(next)`, which indicates the upcoming #feature #version of a #software project. The last version was 0.12.0 — what would you expect the next version to be?
We are talking about Semantic Versioning: https://semver.org/ #semver #versioning
https://pridever.org/ Pride Versioning 
https://github.com/romversioning/romver Romantic Versioning
https://semver.org/ Semantic Versioning
#TIL conda 25.1.1 has access to a #Python 3.13.2 runtime, but doesn't support installing it into conda base. I wouldn't wory too much as long long as the conda packages are kept up to date with a periodic `conda update --all` but the #semver failure bugs me. I expect minor & patch versions to be backwards-compatible.
I'm sure the reason is library dependencies, but that just begs the question. Do any #Pythonistas know why conda's base doesn't support the current stable runtime?
I updated my post that describes the way cargo-semver-checks decides if traits are sealed.
It now describes the latest method I've found for sealing traits: using a const item whose type cannot be named!
Check it out here:
https://predr.ag/blog/is-this-trait-sealed-or-not-sealed/
"When can a trait be implemented without touching `#[doc(hidden)]` items?"
Simple question, extremely complex answer! Most intense 2000 lines I've written in a long time!
Still needs cleanup & refactoring, but it's passing tests!
https://github.com/obi1kenobi/trustfall-rustdoc-adapter/pull/742
Any #java devs out there with some good suggestions for semantic versioning strategies? I've been using Netflix's Nebula Release plugin for years but I'm starting to rethink that approach due to the long configuration times in #gradle. And from what I can tell, the changes to support configuration cache on their side would be significant.
How the heck did I find this?
- I read the Rust docs unreasonably closely.
- I write and test cursed Rust.
I want cargo-semver-checks to get all the edge cases right. This is what it takes.
When you become a GitHub Sponsor, you're funding that attention to detail: https://github.com/sponsors/obi1kenobi
Happy "new cargo-semver-checks release" day!
20 new lints
Full release notes here:
https://github.com/obi1kenobi/cargo-semver-checks/releases/tag/v0.39.0
Today I misremembered a rule that *I helped implement* in cargo-semver-checks.
I described something as breaking when it isn't, and failed to remember the *actually breaking* part. 0/2 on my part.
*This* is why we distill expertise into automation. `cargo-semver-checks` gets this right 100% of the time. I clearly do not.
Merged 5 new lints into cargo-semver-checks today 
It's not even lunchtime yet 
Here's my recap of 2024 for cargo-semver-checks:
63 new lints better linting performance shipped our most-requested features key thing I learned: as a community, we never update versions unless forced to!
https://predr.ag/blog/cargo-semver-checks-2024-year-in-review/
Was ist semantische Versionierung und funktioniert sie auch für Systeme?
Semantische Versionierung hat die komponentenbasierte Softwareentwicklung ermöglicht. Vielleicht auch im Systems Engineering?
https://www.se-trends.de/was-ist-semantische-versionierung/
#Methoden #StandardsMethoden #Abhngigkeiten #nderungsmanagement #Kommunikation #Komponenten #Semantik #SemVer #Software
cargo-semver-checks found the problem in this change, saving the project from breaking SemVer. Manifest linting for the win!
Do you see the breaking change?
Manifest linting in cargo-semver-checks means we also have a path toward catching breakage in *future Rust functionality*!
Take the RFC on package supported targets for example. We'll be able to catch "target no longer supported" breakage!
https://github.com/rust-lang/rfcs/pull/3759
Not a problem specific to #Rust, but language-specific package-managers:
“Debian’s Approach To Rust Dependency Handling” [2022], Ian Jackson (https://diziet.dreamwidth.org/10559.html).
Via Lobsters: https://lobste.rs/s/hrkb76/debian_s_approach_rust_dependency
Forget semantic versioning, use PRIDE VERSIONING! 
https://pridever.org
