This article explains the importance of version schema in software development and how it helps in tracking changes, maintaining compatibility, and troubleshooting issues. It describes the four positions of a version number and their meaning, along with different types of versioning in .NET such as Assembly Version and Assembly File Version. The text also highlights the benefits of using proper versioning, including a clear changelog, improved compatibility, strong-naming, and easier troubleshooting.

Version Schema

First of all, let's talk about the version schema itself, if you look at a Version you have four positions of a version number.

Example:

This is not only a number, each place has its own meaning.

The Major Version (first number)

This Version number will change only when you did a huge major change. For example when you change the complete look of your application, or if you add a new Module that will change the behavior of the application itself. So when you change the major version, you will signal the developers "Hey! Here is a huge change, so you it will not be compatible with your stuff anymore!"

The Minor Version (second number)

The Minor Version will be changed only when you add a new feature to your application and does not affect any compatibility with other dependent applications.

The Revision Version (third number)

The Revision will be changed, only when you add some bug fixes or minor changes (typos or s.th) to your application. If you do more, you must then change the minor version.

The stable / patch Version (fourth number)

This version will be changed every time you build. Sometimes you have a build system, that will change it for you. In .Net  you can insert a * in this place, so the on every build, you have a new randomized number. So, in fact, this will be helpful when you want to bring your version 1.4.3 live, but you must rebuild several times due to manifest changes or other fixes, you will not affect the first three numbers. To keep it low and it does not explode in any high number like 4499 or s.th. else ;)

Versioning Types

There exist's different version types in .net. The Assembly Version itself and the file version. You will see these different types in the Property window of each assembly.

Assembly Version

he AssemblyVersion is a version number that is typically set in the AssemblyInfo.cs file of a .NET project. This version number is used by the .NET runtime to determine whether two versions of an assembly are the same or different. If the AssemblyVersion of two assemblies is the same, the .NET runtime will treat them as interchangeable and use the latest version available. However, if the AssemblyVersion of two assemblies is different, the .NET runtime will treat them as separate and distinct assemblies.

The AssemblyVersion is typically used for strong-naming an assembly. A strong-named assembly is an assembly that has a cryptographic signature that binds the name of the assembly to its version number and public key token. Strong-naming an assembly ensures that the assembly is unique and cannot be tampered with, and allows multiple versions of the same assembly to be installed side-by-side on the same machine.

Assembly File Version

The AssemblyFileVersion is also a version number that is set in the AssemblyInfo.cs file of a .NET project. However, unlike the AssemblyVersion, the AssemblyFileVersion is not used by the .NET runtime to determine whether two versions of an assembly are the same or different. Instead, the AssemblyFileVersion is used to identify the version of the file that contains the assembly.

The FileVersion is typically used for tracking the version of a file for version control and troubleshooting purposes. For example, if a bug is found in an application that is deployed to a production environment, the FileVersion can be used to identify which version of the file was deployed. This can help developers to identify the root cause of the bug and fix it more quickly.

Why use proper versioning?

There are several reasons to use a proper versioning here are the important ones:

1. When you release a "new Version" of your application, then you will ensure this by specify a version number. So that each changeist trackable due to the version.
2. Compatibility: If your application depends on specific versions of external libraries or frameworks, it's important to use the correct assembly version to ensure compatibility. Using the wrong assembly version can result in compatibility issues and cause your application to fail.
3. Strong-naming: If you need to strong-name your assembly, you must use a unique assembly version.Strong namingg ensures that the assembly is signed with a cryptographic key and cannot be tampered with. This is important for security reasons and ensures that your application is not vulnerable to malicious attacks.
4. Troubleshooting: Proper assembly versioning makes it easier to troubleshoot issues that may arise with your application. By tracking the assembly version, you can quickly identify which version of your application was being used when the issue occurred and pinpoint the source of the problem.

Conclusion

In fact, using proper versioning, you will get a little bit more work in planning your software releases, but the payout will come with the benefits. You will get a nice changelog, that you can map to a version number. It can help you out identify bugs and where to change them (if necessary).