The problem is related to the format of revision value. After migration to git, revision became alphanumeric. But windows agent required 2 bytes numeric format of revision for file properties.

What are possible solutions:

Nr
1	take the first 7 chars from sha1 of the last commit and convert string as hex digit	1. hard link to last build commit 2. robust to random change history	1. it is not easy get info about which zabbix_agetd.exe is newer 2. win installer take this number into account  during upgrade process
2	UTC date of last commit	1. relatively direct link to the commit 2. newer agent will get bigger revision 3. robust to random change history	1. relatively wide number: 1556632265 2. MS revision field 2 bytes, but utc should be 8 bytes (till 2038)
3	Number of last commit. We should take into account that history of master and release branches do not rewrite.	1. newer agent will get bigger revision 2. short number (fits in 2 bytes)	1. not present direct link to the commit 2. the history can be changed in the future.
4	Number of Jenkins build	1. newer agent will get bigger revision 2. short number (fits in 2 bytes)	Impossible connect 'build' number with 'commit' without Jenkins logs.
5	delta between UTC date of the last build commit and commit tagged as minor release	1. newer agent will get bigger revision 2. number fits in 4 bytes 3. robust to random change history	1. for first build of new release the revision will be equal to 0 2. not easy to find the last build commit
6	delta between commit count of build point and commit tagged as minor release	1. newer agent will get bigger revision 2. short number (fits in 2 bytes)	1. not present direct link to the commit 2. the history can be changed in the future.

I think we should choose method 3 or 6

Additional question: will new "revision policy" be applied to all agent or only to windows agent ?

Available in:

• 2.2.24rc1 3b87bcd9cde
• 3.0.28rc1 babb8eafcc0
• 4.0.8rc1 64128b7771f
• 4.2.2rc1 b16f45658ac
• 4.4.0alpha1(trunk) a18680803d1