Lmst

If a software package release contains bug fixes and deprecations, do the deprecations make it a minor release (i.e., new, additive features release), or is it still a patch-level release (i.e., bug fixes only), since there are no new features?

In other words, are deprecations new features?

#semver

TIL: #semver (https://semver.org/#spec-item-9) defines a "prerelease" differently than python and dpkg does it:

Semever: 0.1.1-20250101 < 0.1.1 < 0.1.2
debian/python: 0.1.1 < 0.1.1-20250101 < 0.1.2

Why? WHY? WHYYYYY?

🔢 Schon mal über diese krass langen Versionsnummern bei Software gewundert? 🤔
Warum nicht einfach „Version 1.0“ und gut ist? 🤷‍♂️
➡️ Die Antwort steckt in der semantischen Versionierung! 🧠💡

Hier geht es zum Artikel:
👉🏼 https://wattblicker.craft.me/semantische-versionierung

#Versionierung #SoftwareWissen #TechTalk #Entwicklung #SemVer #DevLife #CodeBasics

@horenmar Ha ha - that's the #MicrosoftLogic joke of the day! 🤣

It's amazing that this can happen in a world with #semver .

Suppose an upstream package messes up and releases v4.4 with a breaking change. For some reason (msys2), you need a vcpkg baseline where the package is at v4.5. You need v4.3, and even though v4.3 is in the versions database, you can only get v4.5, because the only versioning constraint available is "version>=": "4", which baseline v4.5 satisfies 🎉🤦‍♂️

#ShamelessTechShaming

Ich habe eine neue Artikel-Reihe gestartet: #Wissensmanagement in der #Architektur

Wie wir mit #AsciiDoc, #Git, #BibTeX und etwas #Perl komplexe Dokumente in der Architektur erstellen und vor allem wiederfinden und #Revisionen tracken.
Außerdem ein paar Punkte warum #MarkDown saugt und #kroki fetzt

https://www.kaishakunin.com/posts/architekturwissensmanagement/01/

#togaf #sabsa #semver

New cargo-semver-checks just dropped, enjoy!

And if you're enjoying, please support the project on GitHub Sponsors 😍
https://github.com/obi1kenobi/cargo-semver-checks/releases/tag/v0.41.0

#rust #rustlang #semver

v0.41.0 release of cargo-semver-checks

# In this release
- 16 new lints, for a total of 164
- Spotlight: Google Summer of Code
- Bugfix: false-positive sealed trait lints

This release requires Rust 1.84+ both to install (MSRV) and at runtime. Future releases will require Rust 1.85+.

# Spotlight: Google Summer of Code

`cargo-semver-checks` is participating in Google Summer of Code, a program aimed at bringing new contributors into open source software development.

This is our second year participating in the program under the Rust umbrella. Last summer, @suaviloquence joined us to design and build the ability for users to configure which lints run on their projects, on which SemVer changes, and with what effect such as raising an error vs warning. This is a foundational capability for our project! For example, it allows users to temporarily disable a lint that exhibits buggy behavior in their project, such as a false-positive.

The application process for this year's Google Summer of Code concluded two weeks ago, and we're currently in the evaluation process. The selected projects will be announced in early May. We thank everyone who applied for their hard work on their proposals, and wish everyone the best of luck!

Bugfix: false-positive sealed trait lints

In rare circumstances, `cargo-semver-checks` had the tendency to mis-classify traits as sealed even though that wasn't actually the case. This manifested as false-positive lints stating that traits have newly become sealed (a breaking change) or that a previously-sealed trait is no longer sealed (a future-compatibility warning).

After quite a bit of work, we were able to diagnose the issue as a logic error in the cycle-tracking code of our sealed trait analysis. #1200 has more information.

This portion of `cargo-semver-checks` has 2000+ lines of test code _specifically_ dedicated to covering its edge cases. This bug made it through all of that without getting caught — that's how complex this space is.

We're grateful to the folks who contributed high-quality bug reproductions to help us diagnose the problem in #1200. We're also grateful to the generosity of our GitHub Sponsors who make it possible for `cargo-semver-checks` to continue powering through this very complex space.

One of the most off-putting things about #Rust is the complete and utter contempt that most of its community has for #semver: A library that is meant to be used by others should explicitly have a version of 1.0.0 or greater.

0.x.y means that it is not ready for actual productive use:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backward compatibility, you should probably already be 1.0.0.

Meanwhile in Rust: “The preferred TLS-library with 186k users, 166 contributers, and 3795 commits is still in version 0.23.26.”

Sorry, I’m not going to use a pre-release cryptography library in production! If this is meant for actual use, give it an according version number!

Also, the custom rules are part of the problem: The notion that you should not have breaking changes when going from 0.1.2 to 0.1.3 is explicitly in violation to the rules that semver puts down, yet the rust community has set up expectations that this is not the case.

And then there is of course the entire mess with huge numbers of transitive dependencies for everything. I was looking at a json library and it depends on an “itoa”-crate that literally just exists to convert integers to strings. Aka: it introduces a completely new point where someone can create a dependency that includes malware, for essentially no gain.

Compare this with C++, where the generally preferred json-library has zero dependencies and is in fact single-header-only.

It’s stuff like this that pushes me back to C++ every time I look at rust. Which makes me sad, because I really like many of the high-level ideas behind Rust. 😞

#cplusplus

Обновил у себя Forgejo с 7.x.x LTS до 10.x.x Stable.

Думал, что придётся попердолиться с поломками обратной совместимости что-то опять поудалять или подобавлять в конфиг.

Сначала натравил на релизноты и чейнджлоги последних трёх мажоров ChatGPT и попросил сделать выжимку.

Почитал, не поверил, пошёл читать сам.

В итоге обновился буквально тем, что у себя в .env файле поменял версию образа с 7 на 10 и дёрнул:

docker compose pull
docker compose up -d

Потом ещё для перестраховки пошёл и проверил с помощью forgejo doctor check --all, что ничего не сломалось.

Там были ровно те же ворнинги, которые были ещё со времён переезда с Gitea на 7.x.x - заодно пофиксил их.

Короче, выражаю свой респект господам из @forgejo за достойный переход на SemVer, достойное ему следование и достойное избегание лишних поломок даже между мажорными версиями 👍

P.S. Надо будет теперь где-нибудь в конце апреля заехать на выходящий скоро свежий LTS релиз и снова долго в ус не дуть обновляя минорные версии автоматом.

#log #server #dev #update #Forgejo #BC #SemVer

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.

#GodotEngine #Godot4 #Android #SemVer

Screenshot of Godot's Android Export options showing Version Code as 101 and Version Name as 1.0.1.

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 .

#rust #programming #semver

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/

#W3C #CleverThis #SemVer #SemanticVersioning #Foss #FLOSS #OSS #CS #Programming #Software

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

#frontend #roolipelit #semver

Формализация принципа Open/Closed: как сохранить обратную совместимость с помощью SOLID

Привет, Хабр! Меня зовут Дмитрий Сурков, я iOS-разработчик приложения для среднего и малого бизнеса ПСБ. Наше приложение состоит из различных модулей и внутренних библиотек, которые связаны между собой, поэтому важно сохранять гибкость и обратную совместимость во время разработки. В этой статье мы разберемся, как вносимые изменения нарушают эти правила, а также как это исправить.

https://habr.com/ru/companies/psb/articles/873612/

#solid #swift #ios #semver

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/

#rust #rustlang #semver

✨ cargo-semver-checks v0.40 is out ✨

https://github.com/obi1kenobi/cargo-semver-checks/releases/tag/v0.40.0

#rust #rustlang #semver

## 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.

#Authentik #CoreUnitNET #IDP #Keycloak #Dex #Containerization #DevOps #SoftwareDevelopment #SemVer #VersionControl #OpenSource #IdentityManagement #DeveloperExperience #TechSatisfaction #SSO #OAUTH

there are two types programming language communities, identified by how they engage with semver

1. the type that labels a package version 0.32474 after its been used in mission critical production code making billions of dollars and literally saving Earth from the goa’uld because, like, the API just isn't stable yet

2. the type that are on version 312.2.42 after a full month of being out. 311 has an optional config change. 313 is going to seem like it does nothing but actually subtly inverts the behaviour of the entire API in a way that seems totally logical to the maintainers and exactly no-one else

#programming #versioning #semver

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…

#SemVer

#SemVer

Client Info