29

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?

Improve this question
0

3 Answers 3

Reset to default
23

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.

Improve this answer
7
  • 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.
    – Klee
    Commented May 31, 2013 at 0:16
  • 1
    @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
    Commented May 31, 2013 at 0:56
  • 2
    "....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
    Commented May 31, 2013 at 1:02
  • 4
    If you can't make changes to a beta, it's not a beta, it's a release.
    – Dave Nay
    Commented May 31, 2013 at 1:57
  • 7
    +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.
    – MarkJ
    Commented May 31, 2013 at 11:26
16

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.
Improve this answer
7

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.

Improve this answer
2
  • 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/…
    – amon
    Commented Sep 23, 2017 at 10:03
  • 1
    @amon Here it is, a shorter quote.
    – ferit
    Commented Sep 23, 2017 at 10:15

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