The MAK ONE Release Versioning Convention: Keeping Track of the Changes
by Jim Kogler
Today I want to talk about MAK’s versioning conventions and release process that helps us and our customers keep track of the changes and improvements. Specifically, patches. What is a patch? What causes MAK to release one? And finally, should customers use them?
MAK ONE products have a version numbering system that typically contains two or three numbers separated by periods, sometimes followed by a letter.
It looks like this:
Major and Minor Releases
The first two numbers are what we call the major and minor “feature” release numbers, and these are what get updated whenever we release major or minor feature releases. MAK typically updates the first number to indicate a whole new architecture, a new protocol, or radical changes. The second number is reserved for more routine feature releases. Feature releases typically happen annually but sometimes they fluctuate between six months and two years depending on our product goals and roadmap.
Maintenance Releases
We change the last number in the versioning convention for maintenance releases; for example, a change from VR-Forces 4.5 to VR-Forces 4.5.1 is a maintenance release. In the case of version 4.5, a maintenance release of zero is implied. You can assume that VR-Forces 4.5.0 is the same as VR-Forces 4.5.
Maintenance releases are special. They introduce no significant changes to the product, which means no impactful changes to the API or configuration. We may add something to the API or various configuration files, but we expect plugins to be source compatible (though you may need to recompile), and we would expect your simulation model set (SMS) to be unchanged. We cannot guarantee NO changes, but maintenance releases just mean that any change will be trivial to make and will have minimal impact. Our goal is always to have customers upgrade easily, quickly, and without worry.
Maintenance releases are fully tested, supported, and available on every platform where the original was released; as such, it takes MAK a considerable amount of work to get a maintenance release out the door. Further, maintenance releases “replace” the previous maintenance release from a support perspective. We will fix bugs for you, but you need to upgrade to the latest maintenance release to get a patch. A new maintenance release becomes our “standard” release and the default product that customers will download when upgrading. Maintenance releases are fully documented, and MAK is rigorous about recording what has changed from release to release.
Patch Releases
MAK understands that our customers work under demanding schedules and sometimes find problems before important demos or project milestones. MAK has developed a system where individual support personnel can quickly issue a patch for a customer if needed.
A patch is versioned with a letter, for example, VR-Engage 2.1a, or VR-Engage 5.6.2f, and is released in alphabetical order. Unlike patches from other companies, MAK patches include a FULL product installer. We typically do not release “partial installs.” The patch looks entirely like a maintenance release, except it is NOT fully tested, likely not available on all platforms, and the documentation hasn’t been updated. This allows the MAK engineering team to get a patch out to a customer in as little as several hours. We release the patch only on the platform the customer needs. For example, VR-Forces 4.5.1a may be available only on Windows, but VR-Forces 4.5.1b may be available only on Linux.
All patches are cumulative, so if you get a “c” patch, you will get all the fixes found in “a” and “b.” The MAK team maintains a full list of every change that goes into the patches and can send you that list with your patch.
After a certain number of patches, the product will go through the full QA process and will come out as a maintenance release. Following the example above, VR-Forces 4.5.2 could be the same as VR-Forces 4.5.1c, except it's fully tested, documented, and available on all platforms.
All maintenance releases and patch releases come from the same source code branch, meaning that they are cumulative. All fixes made for a subsequent patch will show up in the next maintenance release; fixes made in the maintenance branch will make it to the next feature release. So, if your bug got fixed in VR-Forces 6.5.2a, then you can be assured it will be fixed in VR-Forces 6.6.
Sometimes customers ask us if we can create a special patch release *just for them* with only their one fix in it and no other fixes. The answer is almost always no; our process doesn’t support that. It’s not just the infrastructure that makes this difficult; many bug fixes rely on previous bug fixes and supporting multiple builds with only select bug fixes is too cumbersome and error-prone. As a result, MAK tries very hard to avoid this.
Customers sometimes ask if they can get the latest patch release, however, MAK typically encourages customers to stick with the latest maintenance release (not the latest patch). When we release VR-Forces 5.6.2a, new customers will still be downloading 5.6.2 (not the “a”). This is because the patch release “a” may not be available on all platforms. Further, the MAK ONE applications are all built in a stack – VR-Engage is built on VR-Forces and contains several plugins. There may never be a VR-Engage built on VR-Forces 5.0.2a. Further, if the bug fix is obscure (i.e., only affects one customer) the added confusion of incompatibility and undocumented changes may not be worth the risk for other customers.
As with most rules, there are infrequent exceptions. MAK will occasionally release a patch to the public when the change is so small as to have no impact on the upgrade process. For example, fixes to our documentation, or a missed file in packaging. In these cases, the letter is used to indicate a change to the package that is not significant, where a change in documentation may not even be required. In cases like this, the updated package (with the patch version) will appear on our MAK ONE download page and customers can come and grab it as an update. Anecdotally, this has happened about four times in the last twenty years.
While this might sound a bit confusing, it is a system that has enabled MAK to manage many releases over many years, delivering a level of stability that our customers demand and a quick turnaround when customers are in need.
If you have questions about this process, reach out to our team at
