16

So I've been researching and looking into versioning my applications correctly rather than coming up with my own scheme. Semantic versioning is a popular option as many of you probably know, but my applications do not apply to the semantic criteria. By this I mean my product isn't an API. Looking into this, people say semantic versioning is primarily for dependencies.

So my question is, is there a versioning scheme for something like a web application or how can I adapt semantic versioning to suit me.

I came up with the following based on things I could find: So it still uses 0.0.0 = x.y.z

  • x: MAJOR: Significant change to UI or code and/or structure
  • y: MINOR: New features
  • z: PATCH. Bug fixes

This, for the most part, looks like it will work great. Maybe I'm thinking to deeply but when I push a change, not a bug fix or new feature, what is that considered? Patch or minor? I'm just after some advice on how to properly version web applications for an end-user, not an API.

Improve this question
2
  • 3
    What's your purpose? What do you want to communicate? Who needs to know? Why?
    – Laiv
    Feb 28, 2018 at 19:02
  • Is it better to change it like this : Versioning : xyz x: MAJOR: New features y: MINOR: change to UI or code or structure z: PATCH. Bug fixes I think It's better that we use new feature for main number of versioning
    – keivan kashani
    May 12, 2020 at 11:30

3 Answers 3

Reset to default
13

What purpose will this version number for your web app server be? Have you asked yourself whether you even need a version number?

As the consumer of a library, a version number is important, especially if that library adopts semantic versioning. I can tell at a glance how significant a change a new version will be, due to that major.minor.patch semantics.

As the consumer of a desktop application, version numbers become as much about marketing as telling me, the user, what has changed. Semantic versioning becomes less important. MyApp 2018 instantly conveys how new the app is. MyApp v4, less so. Beyond selling it to me, I'd probably only care about the version number if I had a problem and needed support.

Now think about the apps on your phone or tablet. Let's say you have the eBay app installed. What version is it? Have you ever cared? Would you even know how to find the version number without assistance from support? That version is now there purely for that support purpose.

Then we get to web apps. "Hey support, I have a problem. OK, I'll hit F5. Oh yes, that's fixed it. Thanks". So clearly the user no longer needs a version number. So since the user doesn't need it, you need to ask, do you need it for some reason?

If you do, then what for? What would a breaking change mean? Do you want to record whether you just introduced bug fixes, or improvements, or new features? Or do you simply want a marker in eg Git that records when a release occurred? It's likely that "v1", "v2", "v3" ... or even "2018-02-28" will surfice for your needs.

Improve this answer
1
  • The use case I'm exploring is exactly what you say about web-apps. But users are not necessarily tech-savvy enough to know to refresh. So we just end up getting bombarded with alarm errors. Is there any other way that doesn't involve a persistent connection between the client and server? Because versioning feels like the more straightforward way to accomplish this
    – Andrew
    Sep 24, 2021 at 19:57
4

Why you use semantic versioning to version you API? To make it easier for your users (here "users" are other programmers instead of typical "end-users") to consume the API.

When you use a library, lets say - libfoo, in your project you can expect that:

  • when you upgrade from 1.0.0 to 1.0.1 there will only be bug fixes
  • when you upgrade from 1.0.0 to 1.2.0 you can expect some minor new features (for example, the library now implements a new algorithm Parallel_Foo instead of only Foo) or enhancements (for example, the library should be now a bit faster)
  • when you upgrade from 1.0.0 to 2.0.0 you will need to rewrite your code because the API might have changed

You can use the same reasoning when you write an end-user program and release a new version.

If the new release contains only bug fixes increment the z number. If the new release contains some new features (e.g. client-side encryption of cat pictures) increment the y number. If the new release messes with the UI and will require users to relearn how to use the program increment the x number.

An end-user program still presents an interface (the "I" in API), the only difference is that it is a User ... instead of Application Programming ... interface. It still has to be consumed (only by humans instead of machines), can change, and may be backwards incompatible. They are not really that different.

Improve this answer
1

If..

  1. There are no APIs to be used by other external systems (not now, not in the future).
  2. Or, there are APIs but used only by the website itself
  3. Or, there are no APIs at all

then..

You don't need versioning. Versioning in this case is only for yourself (the developer), you don't need to follow any specific versioning pattern.

If you still want to version your website, I'd do it like this (personalized solution):

pushdate_major.minor.patch

Example: 2018-08-15_1.3.2

This way, you can instantly know:

  1. When was the last push
  2. Number of major changes happened
  3. Number of minor changes to current major release
  4. Number of patches for current minor release
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.