141–150 of 151 posts
Earlier quoted context omitted.
> liked the project and the name that I chose it for my hackernews account 14 years ago Some people name themselves `__xXx_ultimatEWeapon420_xXx__` and some people name themselves after a random toy operating system.
Classic nerd habit.
Earlier quoted context omitted.
Semver is semantic . It tells you about the changes in the API, not in the implementation. So it's relevant to the users (ie developers) of that API. If I fix a bug in the implementation that doesn't affect the API itself, the semver doesn't change . So it works to define the versioning of an interface . Release versioning (like vyyyy-mm-dd) is about SRE and configuration management, it's about documenting what is ac…
I can see how you are using the multiple versioning schemes to achieve certain goals, but that does not make your approach "one true way". "Semantic" really means "has some background meaning", and SemVer meaning behind all the numbers is in no way limited to API versioning: I am confused if you are making a proposal to consider it only that, arguing that different schemes should be used for different types of softwa…
So yes, I am arguing it should not be used beyond that.
Horses for courses... semver is about semantic meaning to the consumer of an interface, release versioning is about configuration and SRE, user versioning is about functionality and (for a client app) security.
As for proposing the "One True Way", no, I'm not proposing that, I'm saying that I use 3 different versioning strategies for 3 different use cases.
In a production system that I am involved with, the current production is:
API: v5.0.0 (yes we just introduced major breaking changes, however, we have an endpoint for older semvers)
Release: v2025-10-30 (with release notes saying which API Semvers were available and which versions of the user app)
User app: v3.5.1 (there was a security patch to v3.5)
Earlier quoted context omitted.
I can see how you are using the multiple versioning schemes to achieve certain goals, but that does not make your approach "one true way". "Semantic" really means "has some background meaning", and SemVer meaning behind all the numbers is in no way limited to API versioning: I am confused if you are making a proposal to consider it only that, arguing that different schemes should be used for different types of softwa…
The original reasoning behind Semver was that it described the changes from the point of view of the consumer of the interface. If the interface didn't change, then the semver didn't change. So yes, I am arguing it should not be used beyond that. Horses for courses... semver is about semantic meaning to the consumer of an interface, release versioning is about configuration and SRE, user versioning is about functiona…
Eg. GNU coding standards[1] said the following at least 18 years ago:
You should identify each release with a pair of version numbers, a
major version and a minor. We have no objection to using more than
two numbers, but it is very unlikely that you really need them.
[1] https://cvs.savannah.gnu.org/viewvc/gnustandards/gnustandard...
Earlier quoted context omitted.
The original reasoning behind Semver was that it described the changes from the point of view of the consumer of the interface. If the interface didn't change, then the semver didn't change. So yes, I am arguing it should not be used beyond that. Horses for courses... semver is about semantic meaning to the consumer of an interface, release versioning is about configuration and SRE, user versioning is about functiona…
But very similar versioning schemes have been used by different software for a long time before SemVer was formalized as such: again, if you accept any user interface as the interface, vs API interface (or interfaces for developers) as you originally proposed, I have no issue with that. Eg. GNU coding standards[1] said the following at least 18 years ago: You should identify each release with a pair of version number…
What I'm saying is that there are 3 different "users" (actors/use-cases/your-word-of-choice) for a system and each of them need different information about a system that can be expressed in a specific format and implementation of a versioning schema:
1. Other systems, connecting via a documented API (Semver tells devs when they need to be concerned about changes in a particular release to production).
In this case, the users (other developers) are specifically concerned with changes in meaning of an interface, including new information, changes in existing formats, or removal of information.
By definition, this is semantic and Semver provides a schema to support that. Each digit/component of the semver has a specific meaning associated with it.
2. SRE and operations managing the system in production (a calendar based version tells them when a system was released into production, potentially any hotfixes applied, and what SBOM to consult when operating)
It doesn't have to be calendar based, the release version is an arbitrary label. As long as the interpretation of that label is clear between the development and operations teams, it is fine.
Calendar based labelling is usually appropriate for changes to configuration of a system in production.
3. End users of any UX/UI, noting that some systems do not have end users, only other systems. My example was just one of many different "end user version" schemes. Just look at any iOS apps you have installed and what their latest "release" is.
The versioning here can be anything that is clear to the users. A financial system might be versioned by the financial year, or the release of tax and other codes on a regular basis.
Consumer applications might add arbitrary buzzwords like "ai" or "e" or anything else created by the marketing teams.
Earlier quoted context omitted.
Around 1997 I learned the concept of RTFM! Obviously my father already taught me to look in the DOS and WordPerfect manuals to learn about features and commands one might use. Great learnings. Oh and: https://visopsys.org/about/screenshots/
> Great learnings. Lessons. The word is lessons.
https://github.com/bbarker/Visopsys
(Protected-Mode (PM) switch/handoff code in:
https://github.com/bbarker/Visopsys/blob/master/src/osloader...)
Earlier quoted context omitted.
But very similar versioning schemes have been used by different software for a long time before SemVer was formalized as such: again, if you accept any user interface as the interface, vs API interface (or interfaces for developers) as you originally proposed, I have no issue with that. Eg. GNU coding standards[1] said the following at least 18 years ago: You should identify each release with a pair of version number…
I don't accept that "any user interface as the interface, vs API interface". API has a specific meaning, it is for "Application Programmers", which implies that it is for developers of other systems/applications that interface with the system. What I'm saying is that there are 3 different "users" (actors/use-cases/your-word-of-choice) for a system and each of them need different information about a system that can be…
If you strictly maintain a single API version and expect all users to stay in sync, calendar versioning works there too: it is has different meaning from numbers in SemVer, but it is semantic in that it informs the user of when the changes were introduced in your stream of releases.
Just like it does make sense to use SemVer for desktop software you have paying customers for 2.1 and 3.0.
Your versioning should have a goal and fulfill that goal. Your attempt to shoehorn software types into versioning schemes makes no sense, even if I am with you that SemVer can drive good API development practices if applied to the letter (or can result in you quickly getting to 145.14.7 where SemVer did not really help and is likely not suitable for your product release cadence).
Earlier quoted context omitted.
I don't accept that "any user interface as the interface, vs API interface". API has a specific meaning, it is for "Application Programmers", which implies that it is for developers of other systems/applications that interface with the system. What I'm saying is that there are 3 different "users" (actors/use-cases/your-word-of-choice) for a system and each of them need different information about a system that can be…
I believe you are conflating a few things under wrong categories: something that only has a single "stream" of releases (for instance a web application, but it could be anything, an API or a desktop/phone application) needs to only communicate where it's at for "debugging" purposes (talking about a feature/bug from previous releases, referring to the problem a customer has...). A calendar version works fine as long a…
Remember the major version bumps when it is not backward compatible. New functionality can be backward compatible.
You can keep older semver APIs working with endpoints that support upgrading the older format to the newer internally, which allows you to enable things like sunsetting API versions to provide automated upgrade notifications.
All I'm saying is that user version numbers are more a marketing exercise than anything logical.
Earlier quoted context omitted.
I believe you are conflating a few things under wrong categories: something that only has a single "stream" of releases (for instance a web application, but it could be anything, an API or a desktop/phone application) needs to only communicate where it's at for "debugging" purposes (talking about a feature/bug from previous releases, referring to the problem a customer has...). A calendar version works fine as long a…
If you're getting to a semver of 145.14.7 with Semver then sack your API designer. Remember the major version bumps when it is not backward compatible. New functionality can be backward compatible. You can keep older semver APIs working with endpoints that support upgrading the older format to the newer internally, which allows you to enable things like sunsetting API versions to provide automated upgrade notificatio…
Or do not use SemVer?
All I am saying is that they are a communication tool regardless of the product, and there is no one single answer to which is best based on the type of software being built.
You seem to want to encode good API design practices into a versioning scheme, and I claim it does not work that way ;)
Earlier quoted context omitted.
> Nowadays even iOS will randomly change its UI You and I have very different ideas of “random” I think.
> “You and I have very different ideas of “random” I think.” Indeed, not ‘random’. With respect to iOS26 what word should one use? Premeditated? Deliberate? Maliciously?
"without cause"?