We are developing a software that gets released every few months, and it is either a major version (1.0.x -> 2.0.0) or a minor version (-> 1.1.x). This version is visible in the software, say that we have a variable for it like this:

var version = '1.0.0';

and then it's displayed somehow:


When we release 1.0.0 and start working on "vNext", it just feels wrong to leave 1.0.0 there because all the developers and testers will see a "wrong" version in the app. However, at that point we are not sure what the next version will be called - it might be 1.1 or 2.0. I've thought about possibly just marking the next version as "DEV" so that there is no expectation of a certain version number but am not sure this is a good idea (and it's certainly not in semver format so some other code may be broken if it works with the version number in any way). Another idea was to just call it "post-1.0" but that's not a proper version format, too.

Have you ever run into this situation, and how did you deal with it?

  • You're often not sure how a new feature will work exactly. That doesn't prevent you from doing it some way, knowing that you may have to revise that decision. How is a mere version number different? – Kilian Foth Apr 17 '15 at 10:25
  • 1
    Some projects use the "-pre" convention. E.g., if the current release version with the customers is 1.1.0 and the next release version is going to be 1.2.0, then you call all versions leading up to 1.2.0 with names such as "1.2.0-pre1", "1.2.0-pre2", ... – Brandin Apr 17 '15 at 10:36
  • Your question seems to be "how to uniquely identify developmental software builds when the underlying source code is rapidly changing". Also, you have a secondary question: "how to fix fragility in code logic that depends on parsing the version string in some way". – rwong Apr 17 '15 at 10:38
  • I think also this the common use case for the "tags" feature of your source control change management tools. In other words, you develop on your development branch and then when it is ready for release you tag it. The tagged version should contain the updated version identifier which shows "1.2.0" for example. Some project CHANGELOGs of open source projects sometimes even mention something sometimes like "Updated version number to 1.2.4" as a change. – Brandin Apr 17 '15 at 10:40
  • A third related question is "do I need to increment the version number every time I flip the switch on some experimental, pre-release features". – rwong Apr 17 '15 at 10:41

You use your build setup to populate the var.

Most build engines allow a search-replace pass of a file and compile in the resulting file.

So the actual line in the repo would be

var version = @VERSION@;

And then through the builder's config settings @VERSION@ would be replaced with the actual version when building (possibly adding debug postfixes and commit ID for test builds).

  • I would even suggest putting some commit id in such variable (or in another one). – Basile Starynkevitch Apr 17 '15 at 10:29
  • 5
    Maybe the question wasn't clear but it was more about what that @VERSION@ should be, not how to get it to the code technically. I've updated the Q. – Borek Bernard Apr 17 '15 at 10:31
  • @Borek hat it should be is opinion based. Though including a way to easily identify which commit/branch it was built from is preferable. – ratchet freak Apr 17 '15 at 10:33

One standard answer to this is in the Maven world. Development versions use the next version number with the suffix "-SNAPSHOT". After a release of 1.0.2, for example, Maven automatically increments the version to 1.0.3-SNAPSHOT.


Here is a simple way to do it. Since it must be a higher version then the current, the minimal required increment is a minor version. Use that to start with.

If later the decision is made to change it to a new major version change it again.

Why make it more complex?


I develop in a heavily embedded environment, so I'll add in another option:

Our devices have a query command to grab the firmware version, and will return the result with a 2-byte number on success. The problem with the above responses is that it may be impractical to add tags like "pre" when you're limited on your data output format.

What we've decided to do is add a binary mask to our version number that would not normally be there. For example, a timeline of our development might be:

  • 0x0048 (previous stable version)
  • 0x8049 (first stage beta, working version 0, bit15 is the prerelease flag, bit14 - bit12 used as beta dev stages )
  • 0x8149 (first stage beta, working version 1)
  • 0x9049 (second stage beta, working version 0)
  • 0x0049 (final public release)

I used to work on a project where the version was incremented after every added feature. We used semantic versioning so after each change we could increment the version according to whether it was a bugfix, a compatible or an incompatible change. The release version was the version we arrived at after all changes that got into this release.

This meant that releases were not "continuous": the release after 4.5.2 might be 6.3.1, not neccessarily 4.6.0 or 5.0.0. This was OK in that particular project. Of course if your version is used for marketing to end users, you probably won't be allowed to use this scheme.

Personally, I found this way of versioning very convenient. It removes the issue altogether - each version displays its very own version number, there are no "versions in between" about which you would need to worry.


Multiple approaches are available for this, mostly convention and politics than technical actually.

If you can take research what is done for large open source projects you may find lots of good inspiration.

An example of what I 've done for a project I worked for.

Versions marked Major.Minor.Patch.Build. build was generated by the build system so development versions would only have three numbers whereas "official" (aka automatically created from the build system) versions would have all 4.

The version on the head would always be the next version, so if the last release was 1.3.5, the version committed was 1.3.6.

If we needed to release a minor or major release we would first commit the new version numbers then do the build, then commit the next version.

However, things rarely go perfect first time around so what actually got done was :

1 - Branch to a release branch and bump version if needed (if releasing major or minor) 2 - Bump the version on the main branch so it represents the next version that would be released. (always assumed to be a patch on the last release) Stabilize the version to be released and merge fix on main branch. Work normally on the main branch.

In our situation the version was marked in a file (per-product) containing the first 3 digits, build ID was managed entirely by the build system.

This is just an example. there are many others and variations that you can use. It depends a lot on the work habits of your teams (branch etc) the capabilities of your build system, the marketing of your products etc so no single solution fits all.

Hope this helps.


Instead of using a magic number (variable) that is not "present" while viewing code I suggest another approach:

Do the versioning with directories, e.g.


This way when people are navigating the code they should have little doubt about which version they are in because it's part of the directory path that they are browsing.

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