Stream: ideas

Topic: Roc's semver implementation

Sam Mohr (Jun 23 2024 at 01:11):

@Matthieu Pizenberg I think you mentioned some concerns regarding Rust's implementation of semver with respect to pre-releases and build metadata during this last meetup? If that was you, could you elaborate what you mean by that? roc-semver is still at 0.1.0, so breaking changes are an easy add

Sam Mohr (Jun 23 2024 at 01:20):

It seems like in the proposal for Package Versioning, pre-releases and build metadata are just ignored, which is not the behavior that I took from Rust's implementation. Does the team think that they should be ignored for any particular reason?

Sam Mohr (Jun 23 2024 at 01:24):

I think Rust considers two semvers with the same major.minor.patch but one with a pre-release and one without to be different, such that pre-release versions are considered later

Matthieu Pizenberg (Jun 23 2024 at 07:19):

Thanks for pinging me here @Sam Mohr . So my concern isn’t as much for roc-semver than it is for Roc Package Versioning. Thank you for linking the proposal document! I understand that spec of semver exists and it’s useful to be able to parse it and do things with. What I’d like to avoid is a scenario where this complete form of semver (with pre-release, and build tags) is the one used for Roc packaging. Let me explain briefly why that is.

Matthieu Pizenberg (Jun 23 2024 at 07:34):

Dependency solving is a problem which is NP-complete, as far as we know. So all resolution approaches use some kind of heuristic SAT solver, optimized for the task at hand. And one very important optimization to reduce solving time is to consider versions in ranges instead of all versions as each individually. Meaning we can discover decisions during solving such as all versions >= 1.4, <2.0 are (not)valid, instead of trying to find a decision for each of them existing in that range individually.

The issue with pre-release and similar tags, is that they break the ordering of the mathematical set holding all versions numbers. Because for example version 2.0.0-alpha lives before 2.0.0, and yet we do NOT want it in the solution when a package specifies the range 1.0.0 <= v < 2.0.0 in their dependencies (because obviously 2.0.0-alpha would break the compatibility).

Another important point is that heuristic solvers means that some of the exploration may lead to a dead-end, and a need to backtrack the solver to an earlier decision point.

It is that combination of breaking mathematical ordering of the set, and the need to support backtracking in the algorithm that causes the biggest number of inconsistencies, bugs, slowdowns, bad error messages, ... in all programming languages package managers.

Matthieu Pizenberg (Jun 23 2024 at 07:36):

However, specific overrides, that live outside the realm of version numbers are fine. Let’s say you want to try that new package at a specific github commit, or at the state it is in some local folder. Given a way to override all instances of that package by this specific instance is fine and covers the majority of use cases we have for pre-releases.

Matthieu Pizenberg (Jun 23 2024 at 07:37):

So I guess that would be my plea, but I should take it to the proposal document instead of here I suppose.

Richard Feldman (Jun 23 2024 at 12:02):

this is the right place to discuss! I intentionally don’t enable editing or commenting on the proposals so we can have Zulip be the single source of truth for discussion about them :big_smile:

Last updated: Jun 16 2026 at 16:19 UTC