FlexNet Inventory Agent 2020R2 versioning

[pavol_holes]

Hello,

can someone please explain me how versioning of the Flexera FlexNet Inventory Agent is done?

On https://docs.flexera.com/FlexNetManagerSuite2020R2/EN/InvAgentChg/index.html#AgentChangeLog/ACL_TheLog.html#fiaChg_16.0.1 I see 16.0.1.

On FNMS (on-prem) Inventory Settings I can download agent 16.0.1.

But when I install it and I query WMI using PowerShell I get 16.01.3:

get-wmiobject Win32_Product | Where-Object Name -eq "FlexNet Inventory Agent" | Format-List -Property *

See screenshot:

Did someone missed dot in versioning and it should be 16.0.1.3?

Thanks!

Pavol

[winvarma]

Hi ,

Please go though the agent version format in general.

https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/What-Release-Number-Agent-and-Beacon-Corresponds-to-Each-Product/ta-p/2284 

Not sure what is the reason behind showing the version at the platform level and version numbering once the agent is installed and this might be due to release cycle they are following at FNMsuite level.

Regards

[pavol_holes]

Hi @winvarma,

I'm aware of the versioning KB. But as you can see it doesn't match against that, because FNMS 2020R2 = 16.0.x but when I install the agent I get from WMI 16.01.3 which is in format 16.1.x which would mean FNMS 2020R2.1. Can you see it?

Thanks.

Regards,

Pavol

[pallfrey]

Hi @pavol_holes ,

As noted in my other reply 16.01.3 will not be interpreted as 16.1.3, the zero is significant in our versioning system. Any 2020 R2.1 release will be 16.10.0 or similar, Any 2020 R2 release will be 16.00.0 or similar.

Regards,

Peter Allfrey.

[pavol_holes]

Hi @pallfrey,

okay. Thanks a lot for explanation and discussion.

Regards,

Pavol

[pallfrey · Accepted solution]

Hello Pavol,

Versioning of FlexNet Manager Suite binaries utilizes a four part numbering scheme:

• Major.Minor.Release.Build

So that will give 16.0.1.3 for your example. The final part is the build number which is for internal use only, for customers and external visibility we refer to them by a three part version number (16.0.1) for your example and that will always be our latest build of that release.

This is then further complicated by the fact that different operating systems have different version numbering schemes as standard. Most Unix platforms only support a three part version number, even Windows in some areas only supports a three part version number. For that, we compress the Minor and Release numbers together to form a three part number, 16.01.3 for your example.

Regards,

Peter Allfrey.

[pavol_holes]

Hi @pallfrey,

aha, thanks for the explanation. I'll mark that answer as solution, because that describes the current situation and we can document it for our internal software compliance purposes. But if you don't mind, I would like to continue in discussion.

So now the Agent which I'm installing is 16.0.1.3 which means FNMS Major 2020 R1 Minor 1 Build: 3. Now you: "compress the Minor and Release numbers together to form a three part number, 16.01.3". Which actually ends as 16.1.3.

What will you do with Agent at FNMS 2020 R3 Minor 3 Build 1 = 16.1.3.0 Would that be 16.13.0?

Can you please help me understand why you didn't add dash or underscore symbol while compressing the Minor and Build numbers? 16.0.1.3 would be 16.0.1-3.

Thanks a lot!

Regards, Pavol

[pallfrey]

Hi @pavol_holes ,

The compressed (three part) version number always includes the two digits in the second part so it does actually end up as 16.01.3. Your example is correct, that will end up as 6.13.0 (although build numbers always start at 1).

The reason we didn't consider adding a hyphen or underscore is we like to maintain the same versioning (as much as possible) across all of our supported platforms and some will only support numerical characters. In general we've taken the lowest common format across all platforms for simplicity and consistency but we do take advantage of additional properties exposed on some platforms where sensible.

Regards,

Peter Allfrey.