Who is Semantic Versioning for?

Discussion in 'Byte Chat' started by 607, Aug 18, 2022.

?

Were you confused by 1.10?

Yes. 1 vote(s) 50.0%
No. 1 vote(s) 50.0%
  1. Hi, it's me again!

    I think this might be a subject that some EMC members have adequate knowledge on, and I am almost certain that it is a subject that many EMC members would like to have more knowledge on.
    In software development, there is a standard called 'Semantic Versioning' that is defined here. I have seen many references to it, and when I wanted to make a release on GitHub of my MuseSynthesis console program, I was again encouraged to check it out.
    However, when doing so, I kept hearing about having to write an API, and I don't understand why I would do so. On further consideration, even when writing an API, it seems to me that Semantic Versioning would be detrimental to the informativity of the version numbers of my console program. Just last week, I made a change that broke backwards-compatibility with previous versions of the program, but it would not have required any change to the API (if I'm not mistaken).

    So, who is Semantic Versioning for, and/or in what situations should it be used?
    Tuqueque likes this.
  2. Semantic versioning is flawed in its advertising in many ways.

    Semantic versioning was made with the idea that everything is a library and that everything will need interoperability with some other application. In the JavaScript ecosystem, this statement is often true. However, more often than not, it simply doesn't make sense because most applications do not have any API.

    Rather, I've found that a looser definition is now in use for just about everything, even if an API is not exposed. Major changes or additions are given a major version bump, feature additions are given a minor bump, and bug fixes are given a patch bump.

    As a Minecraft mod developer, this system works very well for me. I bump the major version whenever I update the Minecraft version, I bump the minor version when I add a new feature, and I bump the patch version when I fix a bug.

    As an API developer for Modrinth, however, I do have to follow the strict definition of semantic versioning; Modrinth has a public API which hundreds of thousands of people rely on to not break.

    It's worth noting that Minecraft itself is notorious in not following semantic versioning. It's for good reason, too -- if it did, we would be on Minecraft 674.0.1 by now. Speaking as a mod developer, though, it was really annoying how 1.16.1 -> 1.16.2 broke just about every mod. :p
  3. Wait—is this a figure of speech, or did someone actually retrace this? It does not seem wholly unbelievable...

    Anyway, thanks for your input! I think I agree with your view. I was thinking of Python libraries myself. MuseSynthesis is, indeed, not a library and not intended to be used as such.
    I think it might still make sense to bump the major number for a change that breaks backwards compatibility, though? I'll think about it. :) I hopefully won't have to do that any time soon. :p
  4. It is a figure of speech, but it was based on my estimation of how many total Minecraft versions have been released. There are 654 total versions available in the launcher from rd-132211 till 1.19.2, so I was off by 20.
    FadedMartian and UltiPig like this.
  5. I'll second this, but, to give you some more context for terminal applications:

    For most terminal applications using semantic versioning that I know of (I'm mostly talking about linux utilities like xrander or i3) it is frequently argued (though less often followed) to effectively translate the API ideas to commands or configurations: Major changes might break the config file, or break shell scripts that interface with it, minor changes would only add features scripts and config files can use, and patches would still be bug fixes.

    If your API application is indeed the same as your console application, simply in a different format, I would expect these things to correlate, giving you the ability to use one version number that makes sense for both.
    If you find that API changes and console changes frequently don't correlate, I think it is customary (tough I am not sure) to version your API (via /api/vX/) differently than your main console versioning. Every release would come with a separate "API version" attached to it, which changes independently (eg: "version 1.8.16, API version 2.8.2") This is usually the case if the API is only used for a specific part of the application, or if it does something completely different from console interactions altogether.

    I hope that helps. :)
    FadedMartian and 607 like this.
  6. Thanks for the addition. :)

    MuseSynthesis works on XML files, so I intend to bump the major version number iff input from a previous version crashes or yields different results in the new version. This is not a formal definition, so if you find holes in it, never mind; I hope the idea is clear. :)
  7. Sounds good!

    "This is not a formal definition" -> proceeds to use "iff" to mean "if and only if" :p
    607 likes this.