Hello,

Are you aware that the file version numbers of the ICU DLLs
distributed with Firebird 2.1.1 (and probably 2.1 too) are the same as
those distributed with Firebird 2.0?

You'll tell me 'yes ICU is the same in both'.
I'll argue NO, they're not, at the binary level and at their
dependencies level.

The current ICU DLLs depend on version 8 of Microsoft runtime DLL.
Those that were distributed with Firebird 2.0 depend on version 7.1 of
Microsoft runtime DLL.

Any third-party installer will by default only check the file version
tag of the DLLs to decide wether or not to overwrite them. This will
lead to installations of Firebird 2.1.1 on top of Firebird 2.0 that do
NOT replace the ICU dlls because they're the same version. And
Firebird won't start if the 7.1 version of the MS Dlls are not there
anymore (possibly removed from the local directory as known as
unneeded by any part of current Firebird).

Result? A mess.
I know it might not be considered the role of Firebird Project to
increment the ICU Windows DLL version tag when the ICU software itself
is not updated. But as we take the role of compiling it as part of
the project, _if_ we change the compiling settings (or compiler
itself) such as newer builds are binary incompatible (and changing
their C/C++ runtime dependencies is making them incompatible), we
really should increment the file version number.

Asking people to rely on the file date (how awful) is not a valid
option.
Hopefully there is a workaround for those ready to update their setup
programs but not ready to rebuild the project itself, forking it at
the ICU version resource level : just set the setup script to always
replace the three ICU DLLs no matter their version or whatever. This
is not a really clever thing to do. What's more, facing version
tagged DLLs this is not the thing most people would expect.

With the next build of Firebird (whatever version), it would be much
better to increment maybe the very last digit of these DLL versions.

Remember there are at least two version tags in any Windows executable
or DLL. You might set the "Product Version" to match the exact source
code version of ICU and let the 'q' in x.y.z.q increments itself in
the "File Version" field when something significant happens in the
build process of the official binary distributions.

Thanks,

--
Olivier Mascia
T.I.P. Group S.A.
http://www.tipgroup.com