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:
print(version);
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?
6
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).
3
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.
/the_project/1.0/src/files
/the_project/1.1/src/files
/the_project/2.0/src/files
/the_project/2.1/src/files
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.