Layman’s question: why is systemd not using semantic versioning? Hard to understand if any breaking changes will be coming to distros upgrading to systemd 250. I am assuming it should correspond to something like 1.250.0 if full compatibility is preserved?
The first Semver commit (ca64580) was 14 Dec 2009 with it’s first release (v0.1.0) the next day. The first Systemd commit (f0083e3) was 27 Apr 2005 with it’s first release (0.1) the same day.
I think you’re right that the first stable release of Systemd came after the Semver spec and that various forms of that practice were already around before it. In my (somewhat unreliable) memory it took years for Semver to reach the popularity it has now where it’s often expected of many projects.
I think that semantic versioning is a lie, albeit a well-intentioned one. All it tells you is what the author thinks is true about their consumers’ expectations of their code, not what is actually true, so it can mislead. Having an incrementing release version says the same thing: “Something has changed” and gives the same practical guarantees: “We hope nothing you did depended on what we changed”.
True in this case, but there are ecosystems that will help authors enforce semantic versioning, e.g. Elm where the compiler makes you increase the major version if it can know there are API changes, i.e. when the type of an exported function changed.
“ This makes migrating home areas between different systems cheaper because recursively chown()ing file system trees is no longer necessary.”
Let’s build this overcomplicated thing to save some chown time when you ever move your homedir to a different system. As if that is something you do every week…
If you have VDI implemented on top of GNU/Linux, you have this use-case triggered on average once a day per end-user, not the quietly implied less often than once a week.
Should be merged with https://lobste.rs/stories/xxwypa
Layman’s question: why is systemd not using semantic versioning? Hard to understand if any breaking changes will be coming to distros upgrading to systemd 250. I am assuming it should correspond to something like 1.250.0 if full compatibility is preserved?
It may be as simple as Systemd predating the Semantic Versioning spec by almost five years.
are you sure?
none of the specs on semver.org are dated, but there is a wayback machine snapshot from 2009. systemd 1 was 2010.
I also feel like the practice existed long before the semver spec, but that github co-founder certainly seems to be taking credit for it…
SemVer certainly matches how version numbers were first explained to me in 2007.
yet the guy who added tracking scripts to avatars is like “I propose a simple set of rules and requirements…”
The first Semver commit (ca64580) was 14 Dec 2009 with it’s first release (v0.1.0) the next day. The first Systemd commit (f0083e3) was 27 Apr 2005 with it’s first release (0.1) the same day.
I think you’re right that the first stable release of Systemd came after the Semver spec and that various forms of that practice were already around before it. In my (somewhat unreliable) memory it took years for Semver to reach the popularity it has now where it’s often expected of many projects.
on wikipedia the initial release for systemd is listed as 30 March 2010, without any citation. perhaps it should read 27 April 2005.
also I shouldn’t have assume the initial release was called systemd 1. if they do point releases maybe they are indeed using semantic versioning.
I think that semantic versioning is a lie, albeit a well-intentioned one. All it tells you is what the author thinks is true about their consumers’ expectations of their code, not what is actually true, so it can mislead. Having an incrementing release version says the same thing: “Something has changed” and gives the same practical guarantees: “We hope nothing you did depended on what we changed”.
I don’t see it as a lie, more like a best effort guess at compatibility, which is really the best we could hope for.
Semantic versioning is more of a social contract than a formal proof of compatibility.
With that reasoning, why bother with any communication at all?
True in this case, but there are ecosystems that will help authors enforce semantic versioning, e.g. Elm where the compiler makes you increase the major version if it can know there are API changes, i.e. when the type of an exported function changed.
I don’t think it’s supposed to have breaking changes, is it?
The breaking changes are documented in the release notes, but there’s very few of them considering the scope available.
are you sure they aren’t using semantic versioning? they do have minor releases like 249.7.
[Comment removed by moderator pushcx: Beginning a comment by signaling that you are about to be rude doesn’t make being rude acceptable. ]
“ This makes migrating home areas between different systems cheaper because recursively chown()ing file system trees is no longer necessary.”
Let’s build this overcomplicated thing to save some chown time when you ever move your homedir to a different system. As if that is something you do every week…
If you have VDI implemented on top of GNU/Linux, you have this use-case triggered on average once a day per end-user, not the quietly implied less often than once a week.
Or, in other words, forget about pets.
Also this prevents issues when the user logs in from more than one place - chowning would break the previous sessions.
I always thought they use a centralised database with unique uids. They don’t?
A lot of them do, but there are good reasons not to as well. For example it helps not to trust the remote storage with choosing the file privileges.
https://lwn.net/Articles/837566/
[Comment removed by author]