Cake
  • Log In
  • Sign Up
    • For most of the code I release, I prefer Semantic Versioning. It's made my life much simpler both as an author and as a consumer of software libraries.

      I agree that it's less clear how to apply Semantic Versioning to a user-facing app. I think it can still be useful though, if you think of users' interactions with your app as its "public API".

      Behind-the-scenes changes or minor UI tweaks might only warrant a minor or patch version bump, but a major UI overhaul or the introduction of significant new features could be considered a change to how most users will interact with your app, and thus a change to its "public API".

      That said, I think there's also a strong argument to be made for date-based versioning for user-facing software. It's easy to understand and doesn't require any hand-wringing about whether a change is "big enough" to warrant a major version bump.

    • I agree that Semantic Versioning is a great tool when dealing with software libraries. Whenever a new version of a library I use becomes available, I need to decide whether changing to that version is necessary - or perhaps even important. Similarly, when I'm releasing such libraries myself, I want my consumers to be able to properly make these decisions.

      This doesn't really apply to user-facing software, especially in contexts where users don't have to decide if they really need the update: app updates are typically free, and the cost of downloading updates over a Wi-Fi connection negligible. The fact that updates are also mostly automated means that most users don't even need a publicly visible version. One might even argue that displaying a version number is unnecessarily revealing implementation details that the user doesn't need to be aware of.

      Thinking about the differences between "library software" and "end-user software" some more, my conclusion is that I was probably thinking about this the wrong way:

      With library software, it is a good idea to release often, and then make sure that the version number matches the changes since last release. With end-user software, it should work the other way around. Assign version numbers according to the extent of changes - but only then decide if the new version should be released. In this case, having something similar to SemVer can help with that decision.

      An example:

      First released version of an app gets version number 1.0.0. From there, branch out to two separate code bases:

      - Release, to fix bugs in released app; this will only ever increase the third position (1.0.1, 1.0.2, ...) and should not include new functionality.

      - Development, to work on new functionality; first version after release should increase the first position (2.0.0), subsequent development versions should increase the second position (2.1.0, 2.2.0, ...). Some of these might be made available as Alpha or Beta, but without receiving separate bug fix treatment. If new functionality is ready for release, repeat the process.

      This ensures that there are only ever two code branches to maintain, while at the same time codifying the circumstances that should lead to a new release.

      If this is followed through, it means that end users will only ever see one combination of MAJOR and MINOR. For example, if version 3.11.0 gets released, it means that they haven't seen 3.10.x, and that there won't be a 3.12.x. If that's the case, we're back to the "unnecessary information" part. Does it make sense to replace this with something more readable (code names, perhaps?) - or is actually no one ever looking at version numbers, anyway? :D