Is there any reason for the main DOpus 11 executable to still bear (under Properties) the version number 220.127.116.11?
Besides the oddity of it, I am asking because quite a few "Search for updates" programs are assuming that my up-to-date software is well behind in time and raise flags to this effect.
Thanks in advance for your enlightening reply,
The product version is the important field for determining the overall version of the software package.
The file version is just the version of that one component. (A new plugin DLL might have file version 18.104.22.168 but be part of product version 22.214.171.124, for example.)
Just adding a note on versions - some users have written to us with concerns that Opus 11 is about to be upgraded to a major new version.
Be not afraid! While we never comment on release dates nor plans for new major versions, these are traditionally every 2-3 years. Opus 11 was only released this year so Opus 12 is a long way off yet.
With Opus 11 we have increased the frequency of beta releases so users can provide more rapid feedback on issues addressed. These releases have been almost weekly recently, which means that the sub-version numbers have increased more quickly than in previous years.
As some may remember, earlier this year, to avoid confusion, we dropped the 4th numeral in the traditional version scheme so the current versioning is now only X,y,z or more correctly V.S.B - for Version, Sub-version, Beta release. This current version system means that Opus 11 does not finish at 11.9 and may go to 11.666 yet.
Dear Leo & Greg,
Thanks for both your prompt replies
@Greg: no, I am not worried of too fast a change of version, but rather of the "cataloging" the version correctly;
@Leo: yes, I do understand the difference between file & product version. This being said however, most "Search-for-updates" products (such as - but not restricted to - Sumo) are looking at the main executable (in this case Dopus.exe) for detecting the version of the full product. This tactic works for almost ALL products on the market; the few that don't apply this practice (of having the version of the main executable reflect the version of the full product) are permanently / repeatedly tagged as out-of-date ...
As we are not talking -- as in your example -- about a plugin (or any other secondary file, for that matter), it would be nice to adopt this "best practice" of tagging the main executable with the product's version for DO as well.
Thanks again for your attention to this matter,
If a tool whose entire purpose is searching for updates does not understand the difference between file and product versions in Windows resources, I would expect the authors of it would want to quickly correct that oversight if it was drawn to their attention, since the same thing will affect other software as well.
Have you reported the problem to them?
There is nothing to report: just about ALL the updates searching engines I am aware of so far (including some that are defunct already) explain under their respective FAQ sections that one (the main?) reason for some odd suggestions is related to [some of] the developers not marking their main executable with the same version number as the product run by that executable.
Those engines do NOT have access to the "Help | About" info of the software products, and -- as such -- they ALL check the version of the product according to the main executable of the software pack (for Directory Opus, that would be dopus.exe).
My experience, so far, has been that there are really few software packs that exhibit a discrepancy between the product's version and that of its main executable. Moreover, in most cases, such discrepancy tends to be the result of an oversight.
From what I see, DO is among the very few (single maybe?) that displays such discrepancy by actual choice.
Hope this helps.
Have a great day,
Try reporting it to them. It is a flaw in their design if they can't look at the product version resource, and they must be able to tailor which file and resource they look at for different programs (just as they must tailor how they know what the latest version of each program they can look for is, and which exe is the "main" exe to look at, since neither of those details can always be guessed reliably just from reading the directory listing under Program Files).
It should be very easy for them to address this, and it makes more sense for them to fix their tools and make them more flexible for cases like this than it makes for us to change our internal version numbering system to suit some inflexible tools that are looking at the wrong number in the version resource.
It may be rare but I bet it is even rarer for the product version to not be an equal or better choice than the file version, so they should be looking at the product version anyway. That is the purpose of the product version field.
It took some time, but the people at KCSoftware (the makers of the respected SUMO and other utilities) eventually replied to my bringing to their attention your input (further to your suggestions).
They asked me to share with you the info at < kcsoftwares.com/bugs/view.php?id=2894 >.
May I suggest that from this point on I should be left out of the loop as an intermediate link between GPSoft & KCSoftware, and allow both parties to communicate directly and work towards an agreeable solution to all? Of course, I would be enchanted to know the results of the talks, that should ultimately benefit the users of the software packs produced by the two companies ...
Have a great day,
With respect, there's nothing to be done on this from our side and so no reason for us to talk to them at all. Any fix they want to implement can be done entirely without input from us.
As someone who works in a software company, I may jump in and agree to what greg, jon and leo already said.
File version does not necessarily follow product version. Microsoft e.g., often keeps both versions the same (at least for some office products), but from a neutral view, this doesn't make sense and they don't do it for all applications. If you release a product and bump the product version for all components and you have unchanged files in that new package, which are totally identical to those from the previous version, than there's no reason to bump the file-versions for these. You'd push the product version only and be done. File-version can be seen as a vendor-specific (internal) versioning, while the product version is what (should) concern inventory tools. Additionally, a product version number does not necessarily give a hint on what "named" product you're dealing with. o)
Look this, these are the details of an Microsoft SQLServer 2012 "sqlsrv.exe".
For some unknown reason they decided the file-version to be 2011.11(.)0 and product-version to be 11.0.
Another example is the Windows 7 installation I use right now, it is versioned 6.1.7601. Everything is possible o), just don't expect file-version and product-version to match. If you're lucky, the product version at least, matches what is written on the box, which is the case for dopus.exe and totally makes sense from my point of view.