Semantic versioning for desktop applications [duplicate]

Question

This question already has an answer here:

How does semantic versioning apply to programs without API? (1 answer)

Closed 7 years ago.

I can easily follow the Semantic Versioning recommendations if I develop a library or API, but what if the developed product is a website or a desktop application?

When would you increment a major component in that case?

In case of a complete UI redesign? Or something else?

Thoughts?

Answer 1

Semantic Versioning seems to be at conflict with most desktop application numbering. We solved this by handing over "product versioning" to the marketing department, and we maintain completely separate (but logical to us) versions for all the components. A specific product version then becomes a defined collection of compatible components. Maintaining semantic versioning between components is much easier.

• Klee: Good answer, We have been working to implement something similar. Good examples of places where this happens as well is the Microsoft Office Suite of applications.
• Dave Nay: @mattnz, if marketing has that much influence that they can insist the fix is in 3.2.2, they you just kill the 3.2.2 that is in Beta and start over. That's a business decision that I don't lose sleep over.
• Dave Nay: "....Only option is to decouple "Marketing" versions from anything that might indicate reality." That is exactly what we have done. Marketing could call our product versions 95, ME, SE, XP, Vista, 7, 8 or Blue and it wouldn't affect our internal versions.
• Dave Nay: If you can't make changes to a beta, it's not a beta, it's a release.
• MarkJ: +1 The marketing department must control the "product version" that the customers know about. It's part of marketing, like the brand name, and it's their job to worry about this stuff. The software developers must control the internal product identifiers that enable binary products to be identified and linked back to specific source code. Therefore these two identifiers should be completely decoupled.

Answer 2

I adapted semantic versioning for desktop or web applications, so in our work we are using: X.Y.Z

1. Z is increasing if a release contains just a bug fix, dependencies update or some application internal changes, so no new functionality introduced to user;
2. Y is increasing if a release contains minor changes in UI or just introduces some new feature, or some feature redesign/functionality update which will affect user;
3. X is increasing if a release contains major UI/functionality update, for example: new interface design/layout;
4. New project starts with version 0.1 and minor version is increasing with development;
5. If a project contains all planned functionality for version 1.0 the version should be changed to 1.0.

Answer 3

Old post, but I was looking for a solution and stumbled upon this article of Brett Uglow (permalink) which is the best thing I have ever read about versioning applications which will be delivered directly to end-users, especially desktop applications.

An excerpt from the article:

...

The installer-user

The installer-user is the person who has to install the application. To them, the "public API" of the application is the installation-requirements. But who is the installer-user?

For the Twitter mobile app and desktop app, the installer is (usually) the end-user. The installation-requirements would be a minimum required version of the operating system and an internet connection.

For the Twitter web application, the installer is someone from the DevOps (or Operations) team. They care deeply about the installation-requirements as they need to provision the correct infrastrucure based on these requirements.

Proposal

Given the importance of the installation-requirements of an application to installer-users, I propose that semver be used to version end-user applications using the installation-requirements as the public API with installer-users as the consumers of this API.

In practice, increment the:

• MAJOR version when you make incompatible API changes (e.g. installer-users have to modify their infrastructure (phone/tablet/PC/web-server/firewall config/etc) in some way),

• MINOR version when you add functionality in a backwards-compatible manner (e.g. passing additional data to an already-provisioned API or adding any end-user functionality that does not affect the installation-requirements), and

• PATCH version when you make backwards-compatible bug fixes (e.g. fixing any end-user bug that does not affect the installation requirements).

By treating the installer-users as the consumers of an end-user application, and the installation-requirements as the public API, I believe that semver does make sense and is valuable as a communications mechanism for end-user applications.

• amon: Reproducing the whole post here is probably not OK due to copyright reasons. Can you please summarize the most important points of the blog post instead? In case the original link breaks, I archived the URL on the Internet Archive: web.archive.org/web/20170923100125/https://medium.com/@u_glow/…
• ferit: @amon Here it is, a shorter quote.