I had a question the other day about the version numbering of dotNETInspector, especially in regard to me saying in the March 2014 Update that I wouldn’t be ready to jump to 1.5.0, but then I did release it as 1.5.0 while pushing the unfinished features to a proposed 1.6.0 release. So to hopefully clear things up, I’d like to go a bit deeper into how and why I use the version numbers I use.
In my version numbering system each of the three parts indicate a different level of change to the program. Using X.Y.Z for the sake of an example, X is the major version number, Y is the minor version number, and Z is the patch number.
Major Version Number
The major version number will change for one of two reasons: either an extreme change has occurred in the code all at once, or enough smaller features have been implemented that I can consider it a significantly better version of the program.
The first reason may sometimes be practically invisible to a user, but the code changes are so significant that I feel the need to increment the major version. This is the reason both PC Name Grabber and IPFinder are at 2.0.2 and 2.2.0 respectively – originally both had 1.x.x versions which were written in VB.NET (it is the language I knew better at the time), but I rewrote both from scratch in C++/wxWidgets so that both would no longer require the .NET Framework to run, thus making them more portable. While both programs had virtually the same sets of features before and after the update, the extent of the changes to the code warranted a version increment, if for no other reason than to know which code I had to look at in case a bug was reported.
The second reason is much more subjective. Basically I look at the state of the program at 1.0.0 for example, and then figure out where along the line of features I am planning that I feel the program will be so far improved that it deserves to move up to 2.0.0. In a way I guess I also use proposed major version changes as goals for myself, in that I will only increment the major version when I feel I have done enough work to warrant a major version change.
Minor Version Number
Changes to the minor version number indicate that new features have been implemented, but they aren’t big enough by themselves to warrant a new major version. Under optimal conditions these are the version changes that will happen most often.
A change to the patch number indicates that I have fixed something or made a very minor change that doesn’t really add any functionality. For example BitMaker 1.0.1 was released to fix two bugs, while IPFinder 2.1.1 was released because I updated the program icon. Neither of these added functionality, so they were released with just the patch number updated.
What this meant to releases
Getting back to my original point, when I posted the update in which I said that I wasn’t ready to go to 1.5.0 for dotNETInspector what I meant was that I wasn’t ready to finish the functionality that I had intended for that version, not that the next version would be a continuation of the 1.4.x line. Unfortunately in my excitement to post an update that something new wasn’t too far away, I guess I just worded it badly and may have confused some people.
So essentially this means that the roadmap I have posted for each of my apps is just a guide to what I would like to implement around the time I get to that version number, but they are not final in any way. Essentially every release featuring any new functionality (except for major version updates) will warrant an update in minor version number by a single step (1.4.0 to 1.5.0 for example), even if functionality is missing that was listed for that version, functionality has been added that was listed for a later version, or functionality was added that wasn’t listed anywhere on the roadmap.
So, hopefully this clears up the issue for anyone who was confused by what I said. If you have any questions please feel free to leave a comment or contact me and I will try to explain further. But for now, I’m off to work on the next version of IPFinder.