Please show version numbers on the software downloads page and in the file name

First of all, let me be clear that I know how to see the version number of DxO software once it is installed. The problem is seeing it on your website. It would be helpful to have the complete version number shown on the download page in my account and included as part of the file name that is downloaded. This goes for all of your software: PL, Nik, VP, FP. This is standard industry practice and makes the process of determining whether or not there is an upgrade that I need to download much more straightforward than it is currently.

Yes it would be a great advantage…so I voted


We had got them to do version numbers on the install files in 4 but in 5 that’s been abandoned.

1 Like

Yes, this would be very nice. In the meantime remember that whenever you start PL5(or any of the other software that you mention) will notify you when an update is available.

1 Like

So I’m not crazy… I couldn’t remember having this problem in the past.

A lot of customers spent a long time pressing for version numbers to be part of the file name and with version 4 they were. But we are back to the why should we again. We also pressed for actual information on what bugs were dealt with, never got very far with that though. The way Affinity and other programs list what they are done is a strange alien concept with DXO programers.


Timothy(@tlinn) & John (@John7) I have voted that the numbering should be returned to the PL5 release. A new version of PL4 was released yesterday and it continues with the numbering scheme but as for PL5 …

The variations of the title for PL5 in my snapshot were arbitrarily allocated by me and should have been in line with the numbering scheme shown by the directories used for storing the PL user.config file for each release as shown in the photo below.

The ‘saved…’ element of the (Win 10) directory naming was to remove these config files out of consideration (and to preserve/protect them) when a problem was detected with the 5.1.?.? release losing file export options when inheriting a previous release/build under certain circumstances.

Had I wanted to revert to a previous 5.0.?.? version of PL5 I would have had to work out which .exe I needed with the current release numbering scheme used for PL5, i.e. no formal scheme!!

Trying to determine which version I might want (e.g. is guesswork unless I had changed the .exe filename immediately after installing, as I do when I remember or forget to do when I get carried away with the “excitement” of a new release!!

Checking the properties of a PL5 .exe yields

In this respect PL4 is no better because the details of its properties for the latest release PL4.3.6.32 shows the file version as!!

FastStone Image Viewer uses a name that includes the version number in the exe plus the properties contain the following details:-

So we have little traceability of the code files of PL5 and then we have the question of fixes. This is unfortunately complicated by this very forum where potential bugs can be “paraded” to elicit support or be “shot down in flames” or …

Alongside this “informal” scheme runs the standard error reporting. Personally I would like an “incident” number allocated to every fault when it is raised and a formal fault number then assigned to the fault when formally accepted by DxO as an error.

Similarly a number should be allocated by DxO to a fault reported via the forum when it is subsequently accepted as a fault. Every release should provide access to a list of fault numbers (with a summary) of the faults fixed in that release.

This was the way it worked on the systems that I worked on but then the customers were running 24/7 systems and paying millions for the system and close to a million per year for support!?

Examining Affinity is a better (more realistic) example. I opened Affinity and was immediately informed that there was a new release available which I went to download only to discover I had downloaded it already, so I installed the update immediately. The details of the upgrade are available via a fixed item on the forum and the list is reasonably comprehensive, providing users can recognise their error from the list? The history of previous releases is excellent and accessible in one place.

Arguably the same information is provided by DxO for PL5 except that the 5.1 release only documents “minor fixes” alongside new features (and there have been two of those 5.1 releases in quick succession) but the 5.01 and 5.02 fixes list is more comprehensive and similar to the Affinity release document.

I don’t think that the process is an alien concept to DxO but I do feel that the PL5 developers appear to be under a lot of pressure just now. Neither Affinity nor PL developers provide the level of detail that I would like so that I can identify that “my” fault has been fixed in the release, which then triggers me to go check it has been fixed or, if not fixed, “complain” as politely as I can manage and ask for an approximate time when it will be fixed.

Paperwork is time consuming but I do feel that there needs to be a “more joined up” level of detail from DxO for PhotoLabs. The Hub is playing an increasing role in showcasing the product and I would not want to see it burdened with a detailed list of fixes but it would be good for that list to exist and be accessible.

The Hub in PL4.3.6.32 effectively advertises PL5, which is understandable, but there should be reference to the PL4.3.6 release notes. They can be found and I have attached both to this post.

PL4_release-note_win_EN.pdf (296.6 KB)

PL5_release-note_win_EN.pdf (353.8 KB)


Perhaps something like this would be useful: Release Notes -
Seems like this kind of thing would be useful to the developers as well as customers. (They presumably already use something like this internally.)

Also, an example of IMatch installer version naming: imatch_licensed_2021_8_4_x64.exe

@jch2103 the Release notes example you included is good and the reference numbers should mean something to the originators of the errors or indeed the enhancement requests.

To be honest the naming convention for PL4 is fine but the ‘properties’ ‘details’ should also tie up to complete a professional release procedure. Unfortunately PL5 has abandoned the naming convention completely!