#semver

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/

Read more about it here: https://cleverthis.com/news/clever-semantic-versioning-w3c-submission/

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

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

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

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

#solid #swift #ios #semver

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

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

Many versioning and branching strategies are available. I prefer a simple approach: mainline development using GitVersion for automatic Semantic Versioning.

Branching strategy

Different development scenarios require different branching and versioning strategies. For instance:

Packaged apps with multiple concurrent versions.
In-house web applications with distinct integration, test, and production environments.
Open-source libraries with community development contributions.

I mostly work on commercial web applications with multiple deployment environments but only one production version. I also contribute to open-source projects. My strategy is straightforward: a single main branch with temporary feature branches that merge back into main. Feature Flags are used when necessary for testing without affecting production.

Additional branches are created only as needed, such as for urgent production fixes. For example, if new work is already merged into main, I will create a support/x.y branch from the last release commit for the hotfix.

I build and package the application once, deploying it to multiple environments with only runtime configuration changes.

A simple branching strategy minimizes complexity and accelerates deployment, though it may not suitable for application that need to support multiple versions.

Mainline strategy

The mainline approach keeps the main branch in a releasable state, automatically increasing the version PATCH number with each commit. After a release, the next commit to main is tagged with a new MINOR version number.

Process:

Develop features on feature branches.
Merge them into main via pull requests, increasing the PATCH version.
Builds on main are potential releases.
After a release, tag the next merge to main to increase the MINOR version.
Create a support/x.y branch for post-release fixes, only if needed.
Merge hotfixes into support/x.y and then merge support back into main.

Note: GitVersion also supports release/x.y branches, however they are configured by default for release candidate builds (e.g. 1.5.3-rc.1); for Mainline mode go straight to support/x.y branches.

Version numbering

I follow Semantic Versioning, with MAJOR.MINOR.PATCH format, which has strict semantics for libraries and APIs.

For applications, where there is no public API, I increase the MINOR version with each release and use the PATCH version for builds and hotfixes.

Increasing version numbers

In Mainline mode, the PATCH version increases with each commit to main. Unlike the default mode (which only increase build metadata), this simplifies integration with packaging systems like NuGet and containers.

I use tags to increase MINOR version numbers after each release, although Gitversion has several other ways to increase the version if you prefer. Using tags speeds up subsequent version calculations.

Using GitVersion

GitVersion automatically generates version numbers based on Git history. For instance, after tagging "v1.5", the next merge to main will be calculated as 1.5.1.

GitVersion supports various branching models but I use the simpler Mainline mode, focusing on a single main branch with feature and hotfix branches as needed. I avoid a separate develop branch unless it's necessary, such as for community contributions to an open-source project.

The typical GitVersion.yml configuration I use is:

assembly-versioning-scheme: MajorMinorassembly-informational-format: '{SemVer}+{ShortSha}'mode: Mainlinebranches: main: regex: ^(origin\/)?main$ support: regex: ^(origin\/)?support\/.+$ignore: sha: []

GitVersion's main advantage is that version numbers are independent of the build system, calculated solely from Git history. This is useful for small projects where builds are run locally.

Limitations of GitVersion

GitVersion needs the Git history to calculate version numbers, which can require configuration changes in build systems (that often default to a shallow checkout) and can increase build time and disk space.

Branching diagram

The branching diagram was generated using Mermaid:

%%{init: { 'theme': 'base', 'gitGraph': {'rotateCommitLabel': false}} }%%gitGraph commit id: "0.1.0" commit id: "1.5.0" tag: "v1.5" branch feature/n1-foo commit id: "pre-release 1.5.1-feature-n1-foo" checkout main branch feature/n2-bar commit id: "pre-release 1.5.1-feature-n2-bar" checkout main merge feature/n1-foo id: "1.5.1" branch feature/n3-waz commit id: "pre-release 1.5.2-feature-n3-waz" checkout main merge feature/n2-bar id: "1.5.2" branch support/1.5 order: 2 checkout main merge feature/n3-waz id: "1.6.0" tag: "v1.6" branch feature/n4-hum commit id: "pre-release 1.6.1-feature-n4-hum" checkout support/1.5 branch hotfix/n5-fix order: 2 commit id: "pre-release 1.5.3-hotfix-n5-fix" checkout support/1.5 merge hotfix/n5-fix id: "1.5.3" checkout main merge support/1.5 id: "1.6.1" type: reverse

Other branching strategies

GitVersion supports other branching strategies like GitFlow and GitHubFlow, often involving more complexity and separate develop and main branches. These are more suitable for libraries, APIs, or applications needing concurrent version support.

For complex applications, multiple long-lived support/x branches might be necessary. Alternatively, having separate branches for each environment (e.g., test and production) can clarify what is in each environment but complicate management.

For a detailed discussion on various branching patterns, refer to this article by Martin Fowler.

Conclusions and next steps

Keep your branching strategy simple until complexity is necessary. Start with a single main branch in Mainline mode, using GitVersion for automatic Semantic Versioning, increasing the PATCH number for each build.

For most projects, especially new applications, this approach suffices. Tag subsequent main merges with new MINOR versions for new builds. Create additional branches only when needed.

Fixes can often go directly into main for the next deployment. Create support/x branches only for urgent production fixes when new work is already merged into main.

Keeping it simple ensures smooth project management.

https://sgryphon.gamertheory.net/2024/07/mainline-branching-strategy-using-gitversion/

#BrnachingStrategy #ContinuousIntegration #Git #GitVersion #MailineDevelopment #SemanticVersioning #SemVer #VersionControl

https://pridever.org/ Pride Versioning

https://github.com/romversioning/romver Romantic Versioning

https://semver.org/ Semantic Versioning

#programming #versioning #version #coding #pride #prideversioning #romanticversioning #semanticversioning #semver

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

Slightly disappointed that the title of the latest @25admins episode isn't in reference to a problem caused by #semver being such a steaming pile of shit.

"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

#rust #rustlang #semver

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.

#programming #semver

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.

#rust #rustlang #semver

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/

#rust #rustlang #semver

pretty annoying that docker doesn't support proper semver in tags

#docker #container #semanticVersion #semver

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?

#rust #rustlang #semver

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

#rust #rustlang #semver

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

On HN: https://news.ycombinator.com/item?id=42503163

#Debian #SemVer #Dependencies

@ehmatthes Using semantic versioning, I don't know if the next release is going to be compatible or not, so I don't bump it until I release.

I also don't want to bother evaluating every commit to know when the breaking change happened so I can bump the other number. So I just evaluate all the changes before release and then I bump the relevant version number.

#semver

I think I just figured out how to make cargo-semver-checks A LOT faster

... to the point that future optimization work should target only the ~5 slowest lints, because they are now the long poles in the perf graph by a factor of 100-500x

#rust #rustlang #semver