Like many developers, I have my own specific set of rules for how and when I release updates to Chordious, and how I pick the new version numbers. Earlier today I outlined a system for automatically generating app version numbers, and then thought it’d make for a nice “real-world” example to pop over here and try to explain the rhyme, reason, and code behind the version numbers I use for Chordious.

The first thing to understand is that I have two different release channels, with two classes of builds: “Official” and “Preview”. In short, Official builds are stable, infrequently updated, and targeted for all users, while Preview builds are potentially unstable, frequently updated, and aimed for dedicated beta testers. See more here: What’s the difference between “Official” and “Preview ” releases?

Now, for Official builds, the version looks like this: Major.Minor.Build.

• Major is set manually.
• Minor is set manually and is always an even number.
• Build is set manually and is simply an increasing number.

So for example, the latest Official build as of this post is 2.0.2.

For Preview builds, the version looks like this: Major.Minor.Build.Revision.

• Major stays manually set, as before.
• Minor is set manually and is always an odd number.
• Build is auto-generated in the format YYDDD, where:
  • YY is the last two digits of the year that the code was compiled.
  • DDD is the day of year that the code was compiled.
• Revision is auto-generated in the format HHMM, where:
  • HH is the hour that the code was compiled.
  • MM is the minute that the code was compiled.

For example, if I had released a Preview build of Chordious on August 19, 2016 at 8:40PM UTC, the version might have looked like: 1.9.16232.2040.

So how do I manage all of this? As the post linked to above describes, I use a T4 text template to auto-generate the version information for my builds. The code (as of this post, latest here) looks like this:

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ output extension=".cs" #>
<#
    int major    = 2;
    int minor    = 0; // Official == even, Preview == odd
    int build    = 2;
    int revision = 0;

    string version = String.Format("{0}.{1}.{2}.{3}", major, minor, build, revision);

    if (minor % 2 == 1) // Preview build
    {
        // Auto-generate the build and revision
        DateTime buildTime = DateTime.UtcNow;
        
        build = (1000 * (buildTime.Year % 100)) + buildTime.DayOfYear;
        revision = (100 * buildTime.Hour) + buildTime.Minute;
        
        version = String.Format("{0}.{1}.{2:000000}.{3:0000}", major, minor, build, revision);
    }
 #>
// This code was generated by a tool. Any changes made manually will be lost
// the next time this code is regenerated.
  
using System.Reflection;

[assembly: AssemblyCompany("Jon Thysell")]
[assembly: AssemblyProduct("Chordious")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

[assembly: AssemblyVersion("<#= version #>")]
[assembly: AssemblyFileVersion("<#= version #>")]

So, when I’m working on Official builds, I just set the version numbers at the top of the code. In this case, you can see that I’m working on Chordious 2.0.2. Since the minor version is even, the code just uses the values I’ve set directly. When I’m releasing an update from one Official build to another (ie. with the same minor and major version), I just increment the build number by one. So the next Official build in the Chordious 2.0 line will be 2.0.3.

Now, when I’m done working on the Official builds and ready to start working on the next Preview, I increment the minor version by one. In this case, I’ll then be working on the “Chordious 2.1 Preview”. And now that the minor version is odd, the code will automatically override the build and revision version with each release, freeing me to work fast and not worry about keeping track of version numbers.

Finally, when the “Chordious 2.1 Preview” is over, that is, when the builds have become sufficiently stable, I’ll get ready to push out all the new goodness to normal users. I’ll increment the minor version to two, and reset the build and revision to zero. At that point I’ll release Chordious 2.2.0 in the Official channel and switch to only fixing major bugs.

Why this whole odd / even switch? Version numbers in general help me keep track of user feedback (so I know which version they’re having problems with) but it also makes it very easy to tell if a person is using an Official or Preview build. It also helps me manage my time, as I switch between “rest” periods of maintaining “Official ” builds (maybe focusing on documentation and tutorials) and “active” periods on Preview builds (where I’m coding like a madman).

As for the major version, when I update that, it’ll be because I feel like I’m releasing a whole new app. When I stopped working on Chordious 1.0 (Classic Chordious) and rebuilt the entire app from scratch, that was worth bumping the major version number. At this point I have no idea what a Chordious 3.0 would look like, so that major version isn’t going to change for the foreseeable future.

Did you find this interesting? Would you like to see more “behind-the-scenes” posts like this? Sound off in the comments!

/jon