-2

For a frontend web app version 3.9, we have a visual change that I would constitute as a backwards compatible (as far as the API) new feature. Therefor, my SemVer instinct is to bump the minor version number.

But how do I do that when we're at 3.9?

Kyle Vassella
  • 111
  • 6
  • 2
    I don't understand the question. After 3.9 comes 3.10, that's obvious. Is that really your issue? But more important: you say this is a frontend web app, and mention "an API". What exactly is this - a frontend app or an API or both? – Doc Brown Dec 06 '22 at 07:25
  • 1
    Can you clarify your question? I have read it a dozen times, but the best I can interpret it is that you are asking "What is 9 + 1?" But I can't imagine that a professional software engineer would ask that question, so I am assuming I am interpreting it incorrectly. – Jörg W Mittag Dec 06 '22 at 10:10
  • @DocBrown It's a pure front end app, no BFF or API in the codebase. I referenced an API because of this portion of the official SemVer docs: https://semver.org/#:~:text=Major%20version%20X%20(X.y.z%20%7C%20X,when%20major%20version%20is%20incremented. – Kyle Vassella Dec 06 '22 at 11:10
  • 1
    Well, since you cited the docs, did you notice the paragraph #1 which says *"Software using Semantic Versioning MUST declare a public API"*? So without an API, you are completely free to choose your next version number, maybe under marketing aspects. I also recommend [How does semantic versioning apply to programs without API?](https://softwareengineering.stackexchange.com/q/255190) – Doc Brown Dec 06 '22 at 11:47
  • 1
    This bring me back to the days of when the next update after v0.9 of an early access game (KSP to be precise) was announced; people were excited that this clear meant they were going to release the final game. – Flater Dec 07 '22 at 01:54
  • 1
    @Flater: Ruby used to have the even=release, odd=devel distinction. However, when Ruby 1.9 (to become 1.10) came around, they discovered that there was a *lot* of b0rken code out there that did string comparisons on version numbers … including the Ruby developers' own build scripts. So, they opted to do 1.9.0-x for dev and then 1.9.1 for release, except that release was b0rked as well, so the first stable release of Ruby 1.10 got the number 1.9.2. They abandoned the even/odd stuff immediately after that. – Jörg W Mittag Dec 07 '22 at 19:43

2 Answers2

5

Use version 3.10 since it is a backwards-compatible new feature. Semantic versioning does not limit you to only 10 revisions of a particular major/minor version. I'm using version 1.73.0 of VS Code and 107.0.5304.121 of Chrome, and neither is unusual in terms of versioning.

mmathis
  • 5,398
  • 23
  • 33
4

Semantic Versioning is intended to version public APIs, usually in the form of packages or libraries. It is not designed for use in versioning applications. This will prevent you from strictly implementing Semantic Versioning as it's defined in the specification, but you can use the general ideas.

If the change to the application is "backwards compatible" in the sense that users who use the system today won't experience changes in their workflow or their use of the application, the correct action would likely be to increment the minor or the patch version. New or modified features/functionality would trigger a minor version increment (making the new version 3.10.0) while non-visible changes (like refactoring or technical debt paydown) or cosmetic changes (like changing colors or minor layout changes) may trigger a patch version increment (making the new version 3.9.1).

Since Semantic Versioning doesn't offer explicit guidance for applications, it would be useful for users consuming the version information to understand updates and changes to have a reasonably clear (and application-specific) definition for what constitutes major, minor, and patch releases.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • 1
    This is the correct answer. SemVer is not for consumer/end user facing applications. Give versions a catchy name or some predictable pattern, and users will be fine. SemVer is meant for a) Developers to understand breaking changes; and b) for package managers when determining which version of a package to install. – Greg Burghardt Dec 06 '22 at 13:24