You might want to have internal version numbers of your application to better manage your internal development processes. However, these numbers are of little use for the user.

The usual purpose of version numbers is to tell the user if their application is up-to-date or not. When this is not within their control, it can at least be useful for support personnel to verify that they received the latest version. But when you have a software-as-a-service where all users share the same deployment, there is little reason to communicate the version number to them.

An exception could be when you aren’t the only one who offers the service. When you only licensed the software or are licensing it yourself so others also offer the same software as a service, it could be useful to communicate the version number to the end-user so they can compare which provider offers which version and also be aware of the version used by their provider in case there are relevant differences in usage.

There are two possible consumers of version numbers. Your internal processes and people using your service.

With internal processes, version numbers help you identify when something was fixed and what has changed since them. By saying “we fixed this in version 1.2.3” you know where that was done and if you are now experiencing the same bug, you’ve got a regression. By being able to identify when it was fixed or implemented (with a version number) you can now narrow down what you need to do to fix it.

Consumers of the service can also use version numbers. Not all consumers need to know version numbers, but it is something that can help them. By saying “these bugs were fixed in version 1.2.3 which was deployed on some date” you, as the consumer know that bugs that you may have reported are fixed. Furthermore, when reporting bugs you have the opportunity to say “this was fixed in 1.2.3 but now in 1.2.5 it is broken again.” This is possibly valuable information for reporting bugs.

Many times, software as a service also has an API for interfacing to it. This API should be also versioned. You can see this with the Stack Exchange API and Google’s data APIs. An API is very much like a library which is hosted on another server. Just as libraries are versioned, so are APIs.

The purpose of a version number in these cases is to allow more efficient communication of the information about what software something was reported in, fixed in, and currently running. That there is only one instance of the ‘currently running’ doesn’t lessen the usefulness of the first two points. It is useful for internal and external alike.

Consider also that unless you are offering an API, semantic versioning is not necessarily as useful. I’ve worked in situations where the build number from the continuous integration server was sufficiently useful for a version number – “production is running build 123, we fixed that in build 145 which is currently being tested in the QA environment. The current build is 155.”

User facing code does not need version numbers.

But if you are writing code that is consumed by external developers, then you absolutely should offer version numbers, and ALSO maintain multiple versions on your site. With a clear deprecation policy. Doing that will give you the freedom to make potentially backwards incompatible changes to your API, and then lets people who depend on you to upgrade when it is more convenient for them. And doing so is not as hard as you might think in the days of AWS since you just maintain servers running an old version and launch new ones using the new one. Release to the old when you need to, and then decommission them when you are done.

Yes, I know that Facebook is not good about doing this. But they are also infamous for releasing code that unexpectedly breaks people using their APIs. And I know quite a few developers who dearly wish that they had any alternative to Facebook. Facebook successfully locks developers in because they have the users. But you don’t have that. If you make developers feel that way about using your service, they will leave.

I would go back to the real purpose of version numbers: to uniquely identify a particular body of code. This is important in a lot of places, but there are several cases where I could see forgoing showing them to clients:

• They are used by clients who need to update (which you explicitly said you weren’t dealing with). This also includes clients who would need to do comparisons, such as comparing how software works between two clients.
• They are useful to developers who have to debug situations with the customer.
  • If it is easy for the developers to know what version they are working with, such as “there is only one version to work with at any point in time,” they don’t need numbers.
• You are working with software where the version of the software isn’t as important as other factors. For example, if you are working with AIs, the state of the AI is far more meaningful than the version of the code in a lot of situations.

Absolutely use versions for customers. Google and Facebook do this as major versions. Check your facts on that one.

Of course there are internal versions but the outward ones should be stable in terms of the contracts/signatures and responses. Upgrades then don’t break customers and newer versions can do away with cruft as needed. You can also announce a time when your legacy versions will no longer be supported and have the ability to specify what version you mean. That’s not possible if you don’t support versioning customer Apis.

If your SaaS Solution consists of client applications like Android , IOS Apps etc.
You might want to version your Server application in order to have a Version Compatibility Mapping between your Server App and your Client Apps.

Some might say : that’s why you have API versioning but that’s not the same.

Sometimes the API might remain Intact but internal business logic-rules might change , requiring corresponding changes on the Client apps also.

Well, I am a newbie to industry but so far what I have known is versions are always helpful in terms of development and our internal management. User may not be interested in what and how you are working on your version controlling system or whether you are launching alpha, beta versions. But at the same time when we do update a version we want to convey the users that the update is really important, this identifies version and at the same time users can compare two versions. Just as android does, we do compare the OS updates and compare them so it’s easier for the users sometimes too.