After lots of searching, I think I finally worked out how to use #Godot's Version Code and Name fields...
The fact that the Code is an integer was confusing, as I'm trying to use semantic versioning. So in order not to have random integers assigned to my semver Name, I set the integer to the same as the semver name, but with the dots removed. Therefore v1.0.1 = 101. Hopefully this works going forward.
This episode of #OpenSourceSecurity talks to @predrag about cargo-semver-checks
it's a #Rust tool that can help you figure out if you broke #semver, it's pretty awesome
We also touch on the difficulty of detecting breaking changes, sustainable open source, and what's to come for semver checking
It's a fun chat and you'll learn a lot
https://opensourcesecurity.io/2025/2025-04-cargo-semver-checks-predrag-gruevski/
@joshbressers loved the cargo-semver-checks episode. It was neat to see that the problem was way more complex than I understood (definitely dunning Kruger topic for me). But it was even cooler to learn that it could be applied to #python .
My first W3C specification has been posted by the W3C. Super excited, cant wait to get the others in!
https://www.w3.org/submissions/semantic-versioning/
Read more about it here: https://cleverthis.com/news/clever-semantic-versioning-w3c-submission/
First of all, I moved instance! I am now self hosting my own #gotosocial instance, which uses the #Mastodon #API, but is easy to self host, and is super chill on the resources. This also means that I can now post long form content! 5000 characters is a blog post in itself, so I can blog AND microblog.
Secondly, I released 1.1.1 of the #alectors library for #nlproc with #rl. I should probably start keeping a changelog or a release log, but I am just getting to grips with what #semver is and how to use it in general. As always you can find the source code at https://erga.apotheke.earth/aethrvmn/alectors which is yet another #selfhosted project, a git #forgejo.
Tänään lapsia nukuttaesa laitoin ulos viime viikonloppuna AI:n koodaaman uuden version mun harrasteprojekti Pelilaudasta. Jonka on muuten testannut myös AI.
Versio on nyt 17.0.0.
Kuulostaa tosi juhlalliselta. Mut oikeesti - koska semanttiset versiot - tossa julkaisussa ei ole mitään hienoa tai uutta. Siis sellaista mitä käyttäjä näkee. Jos ei lasketa muutamaa samalla korjautunutta pikkubugia.
Tän versiointimallin keksinyt tyyppi ei selkeästi ymmärrä markkinointia
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
![## In this release
- 21 new lints, for a total of 148!
- Spotlight: `#[doc(hidden)]` and sealed lints
This release requires Rust 1.83+ both to install (MSRV) and at runtime. Future releases will require Rust 1.84+.
## Spotlight: `#[doc(hidden)]` and sealed lints
When is "this trait can be implemented" part of the trait's public API?
At a high level, the answer is: when writing an `impl` of that trait for our own type doesn't require using any `#[doc(hidden)]` items. But you've been following `cargo-semver-checks` long enough to know the *full answer* is much more complex. And getting the right answer here affects the correctness of a ton of lints!
Good news! This `cargo-semver-checks` release ships with a much more sophisticated system for analyzing whether traits can be implemented or are instead "sealed." The new system is more thorough, more nuanced, and faster to boot!
Read more about it here: https://predr.ag/blog/when-is-trait-can-be-implemented-public-api/](https://media.hachyderm.io/media_attachments/files/114/127/844/400/521/630/original/0beaa5f8bf86ee5e.png "## In this release
- 21 new lints, for a total of 148!
- Spotlight: `#[doc(hidden)]` and sealed lints
This release requires Rust 1.83+ both to install (MSRV) and at runtime. Future releases will require Rust 1.84+.
## Spotlight: `#[doc(hidden)]` and sealed lints
When is \"this trait can be implemented\" part of the trait's public API?
At a high level, the answer is: when writing an `impl` of that trait for our own type doesn't require using any `#[doc(hidden)]` items. But you've been following `cargo-semver-checks` long enough to know the *full answer* is much more complex. And getting the right answer here affects the correctness of a ton of lints!
Good news! This `cargo-semver-checks` release ships with a much more sophisticated system for analyzing whether traits can be implemented or are instead \"sealed.\" The new system is more thorough, more nuanced, and faster to boot!
Read more about it here: https://predr.ag/blog/when-is-trait-can-be-implemented-public-api/")
I have now installed and tested Authentik for CoreUnit.NET. So far I am satisfied. Keycloak, dex and other IDP's made me dissatisfied in some steps. As a developer I just dont like the container image taging, please use semver so I can pin major/minor versions.
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?
"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
![An example of a "public API sealed" trait is:
pub trait Example {
#[doc(hidden)]
type X;
}
Any impl of Example outside of its crate must name the Example::X item, and in doing so refer to non-public-API. Therefore, such an impl is outside the public API of Example, and may suffer breakage outside of major version bumps of Example's crate.
Crates can be public-API-sealed in many ways, including:
- #[doc(hidden)] (without #[deprecated]) on associated types without a default
- #[doc(hidden)] (without #[deprecated]) on associated constants without a default value
- #[doc(hidden)] (without #[deprecated]) on associated functions / methods without a default implementation
- associated functions / methods taking an "importable but not public API" parameter
- associated functions / methods returning an "importable but not public API" type
"Importable but not public API" means:
- The item has at least one path by which it can be imported from an external crate. That path passes through at least one item that is simultaneously #[doc(hidden)] and not #[deprecated], such as the imported item itself, a module, or a re-export).
- The item has no paths by which it can be imported such that no item along that path is #[doc(hidden)] and not #[deprecated].](https://media.hachyderm.io/media_attachments/files/113/920/157/622/808/067/original/d53eaa21a8fe7239.png "An example of a \"public API sealed\" trait is:
pub trait Example {
#[doc(hidden)]
type X;
}
Any impl of Example outside of its crate must name the Example::X item, and in doing so refer to non-public-API. Therefore, such an impl is outside the public API of Example, and may suffer breakage outside of major version bumps of Example's crate.
Crates can be public-API-sealed in many ways, including:
- #[doc(hidden)] (without #[deprecated]) on associated types without a default
- #[doc(hidden)] (without #[deprecated]) on associated constants without a default value
- #[doc(hidden)] (without #[deprecated]) on associated functions / methods without a default implementation
- associated functions / methods taking an \"importable but not public API\" parameter
- associated functions / methods returning an \"importable but not public API\" type
\"Importable but not public API\" means:
- The item has at least one path by which it can be imported from an external crate. That path passes through at least one item that is simultaneously #[doc(hidden)] and not #[deprecated], such as the imported item itself, a module, or a re-export).
- The item has no paths by which it can be imported such that no item along that path is #[doc(hidden)] and not #[deprecated].")
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 #rustlang community, we never update versions unless forced to!
https://predr.ag/blog/cargo-semver-checks-2024-year-in-review/
Doc Freemo 
