Specifically I’m talking about assigning version numbers to your own code and manipulating those versions in CAL / AL and PowerShell.
There are lots of different systems for assigning a version number to some code. Some incorporate the date or the current year and day number within the year. Loads of background reading here if you’re interested.
The system we typically follow is:
Version number = a.b.c.d where:
- a = major version – this is only incremented for a major refactoring or complete rewrite of the software
- b = minor version – incremented when a significant new feature is implemented
- c = fix – incremented for small changes and bug fixes
- d = build – set to the ID of the build that created it in Azure DevOps
This system isn’t perfect and we don’t always follow it exactly as written. The line between what is just a fix and what is a new feature is a little blurry. We don’t run CAL code through our DevOps build process so they don’t get a build ID like AL apps do. Hit the comments section and tell me how and why you version differently.
Regardless, the important thing is you give some consideration to versioning. It is especially important that two different copies of your code must not go out to customers having the same version number. This is especially true for AL apps. If you want to publish an updated version of an app it must have a higher version number than the one you are replacing.
There are several situations where we need to work with version numbers in code and in scripts.
- In the build process – reading the current version from app.json and setting the last element to equal the build ID
- In our PowerShell script that creates a new navx package from CAL code (yes, we use v1 extensions. Not now, let’s go into that some other time)
- In upgrade code – what was the previous version of the app? Was it higher or lower than a given version?
If you are considering, like we used to, just treating version numbers as strings…don’t. Think about it:
Treated as versions 1.10.0 is greater than 1.9.0 but when treated as strings it isn’t. That led us to split the versions into two arrays and compare each element. It worked, but it was convoluted. And completely unnecessary.
Some bright spark in our team wondered why we can’t just use .Net’s version type. We can.
Use a DotNet variable of type Version. Construct it with the version number string. NAVAPP.GETARCHIVEVERSION returns a string that can be used.
You can use the properties of the variable to access the individual elements of the version and its methods to compare to another string (less than, less than or equal to, greater than, greater than or equal to).
Version : DotNet System.Version.'mscorlib, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b77a5c561934e089' Version2 : DotNet System.Version.'mscorlib, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b77a5c561934e089' Version.Version('1.10.0'); Version2.Version(NAVAPP.GETARCHIVEVERSION); IF (Version2.op_LessThan(Version) THEN BEGIN //some upgrade code that must be run when coming from an older version than 1.10.0 END;
Declare a variable of a given DotNet type using square brackets. Create a new version with new, Parse or TryParse. The latter expects a version variable passed by reference and returns a Boolean indicating whether a value could be assigned.
Access the elements of the version through the properties of the variable.
C:\> $Version1 = [Version]::new(1,10,0) >> $Version2 = [Version]::new('1.9.0') >> $Version1.CompareTo($Version2) 1 C:\> $Version = [Version]::new(1,10,0) >> $Version.Minor 10 C:\> $Version = [Version]::new() >> [Version]::TryParse('monkey',[ref]$Version) False
AL has a native Version datatype. As above, create a new version either from its elements or from a string. NavApp.GetArchiveVersion returns a string that can be used (for migration from v1).
To get the version of the current module (app) or of another app use NavApp.GetCurrentModuleInfo or NavApp.GetModuleInfo.
var Ver : Version; Ver2 : Version; DataVer : Version; AppVer : Version; ModInfo : ModuleInfo; ModInfo2 : ModuleInfo; begin Ver := Version.Create(1,10,0); Ver2 := Version.Create(NavApp.GetArchiveVersion()); if Ver > Ver2 then begin //some upgrade code end; //version of the current app NavApp.GetCurrentModuleInfo(ModInfo); DataVer := ModInfo.DataVersion(); AppVer := ModInfo.AppVersion(); //app version of the first dependency NavApp.GetModuleInfo(ModInfo.Dependencies().Get(1).Id(),ModInfo2); //dependencies is 1 based, not 0 based AppVer := ModInfo2.AppVersion(); end;