target setting / version info

[Wolfgang]

Hello,

when releasing a new version of a software I usually update the 'version info' dialog in the target settings. I just realized that these settings are different for debug and release mode... why is it so? One is going to distribute the release version, not the debug version, so why are there two separate entries one has to maintain? Typically, I am running the debug mode, and only at the very end I switch to relase mode. Hence typically I adapt the settings in the debug mode (year, major/minor release number) - so far I had assumed that this is the identical version info as for the release mode, but no...

Wolfgang

[Peter_Prinzen]

Hi,

have you tried to auto-increment the version info by adding a "+" to the string (1.0.0.1+) (in top part, numeric information)? This will increment the number with every release-built, the debug-built will not change them. You can then refer to product or file-version in text information by using %f1.%f2. ... or %p1.%p2.%p3.%p4

Peter

[Wolfgang]

Thanks Peter,

yes, I am using the autoincrement, too.

My question is: in debug mode, file version reads 2.4.1.42+

while in release mode file version is 2.2.0.82+

I am wondering why 2.4.1 <> 2.2.0; I understand that .42+ <> .82+ due to the autoincrement.

[LuisG]

Hi Wolfgang,

As of CVI 2010, all these settings are per-configuration. They apply to the configuration that is specified in the Target Settings dialog -- the parent dialog of the Version Info dialog. Note that one of the values in the configuration ring is "All Configurations", so you can, if you choose, set the same value for all configurations.

If you ever want to confirm the scope of any option in CVI, you can always check the "Persistence of LabWindows/CVI Dialog Box Options" topic in the CVI help.

Luis

[Wolfgang]

Hi Luis,

Thanks for adressing the issue!

1) Is there any reason why there is a version info for the debug? Usually I am working in the debug configuration, and once the code is getting ready, I update the version info dialog (which then defaults also to the debug mode; only later I switch to release mode to check additional compiler warnings, using external compilers clang or Intel. At this stage however I don't remember to also address the version info). Phrased differently, who might be interested in a version info of my debug? Users care about the release only... I understand that it might make sense to have a version info for 32 bit releases and 64 bit releases - but I find it more a disadvantage than an advantage to have separate version infos for debug and release. No such big issue just wondering. (The all configuration settings does not allow to have one 32 bit info and one 64 bit info)

2) I just tried the all configuration info and found that it is not just a fifth configuration but behaves quite differently: Preview is not possible, and several fields are dimmed (although it's possible to change these dimmed entries), could these be bugs?

Wolfgang

[LuisG · Accepted solution]

1) Well, the thought was that in most cases the version of the debug binary isn't important, in which case users can leave it as the default (1.0.0.0). But if someone does cares about the version then they can set it to something else, or enable auto-increment, for example.

If you don't care about the version of the debug binary, you can still go ahead and set them both to the same value, initially. You can enable auto-increment in both cases, and each configuration will increment independently, so that shouldn't be a problem. This way, you don't have to remember to change it whenever you start building release builds.

You're correct about the "All Configurations" not allowing you to have different values for 32- and 64-bit. I guess in that case, you just need to go into that dialog twice. Once for the 32-bit release config (assuming you only have one of these) and once for the 64-bit release config (assuming you only have one of these). Since you don't care about the debug versions, then you can just leave them set to the default.

2) Preview is not possible because you need to have a specific configuration selected in order to preview the variable subsitutions. For example, the values of the %rel_dbg and %arch variables depend on the configuration, so it doesn't make sense to preview when you don't have a specific configuration selected.

The dimming of option values is also intentional. It's a conventional way of indicating that some options have different values when you're editing more than one object. For example, when you edit two numeric controls in the UI editor and they have different labels, then the dialog will show you the label of one of the controls, but it will dim it. This doesn't mean that you can't change it. You can change it, and whatever you change it to will apply to both controls or, in this case, all configurations. It's just to indicate that the dialog can't show you all the values.

Actually, in looking at this dialog again, I did find a bug and that is that the File Version and Product Version controls don't seem to be dimming their values even when they are different. Those should also be dimmed, just like the other controls in that dialog.

Luis

[Wolfgang]

Thanks, Luis, for your patience in explaining,

but I have three more questions:

1) Concerning your first aspect, the help says: LabWindows/CVI increments fields only for successful builds of a release configuration - so I still see no real use of an independent debug version info if it is updated only together with the release version.... (Never mind).

2) I still seem not to fully understand the purpose of the 'All Configurations' setting: Let's assume I have entered a comment 'Official Release (32 bit) built ...' in the release version info, and the corresponding comment 'Official Release (64 bit) built ...' in the release64 configuration. 'All configurations' then displays the 32bit comment, while 'all configuration' implies that this text will show up in all configurations, i.e. 32 bit and 64 bit?

3) In the 32bit info, I use %basename which translates to something like MyProgram in the Preview. In the 64 bit info, I also use %basename which surprisingly translates to a former name, ala MyEarlierProgram. So %basename also seems to be version dependent? The same is true for %filename. 

I am still confused...

[LuisG]

1) The history of this is as follows:

a) From the beginning of CVI, there was always a version number which applied to all binaries that you created. There were no configurations then. Also, there was no such thing as auto-increment. Users would have to explicitly set the version number to whatever they wanted.

b) Some time later, the notion of separate release and debug configurations was introduced. The version info, along with almost all other options, applied to both configurations. There was still no auto-increment.

c) Then, auto-increment was added. When auto-increment is enabled, the simple act of building your project would change the version number. But because the version number was shared accross configurations, and it didn't make sense for debug builds to "interfere" with the release build number, auto-increment was only enforced in release builds -- hence that sentence in the help.

d) The 64-bit configurations then came along. This simply increased the number of configurations from 2 to 4 but had no meaningful impact on this issue.

e) Custom configurations were introduced in CVI 2010. This required most global options to become configuration-specific. We added a note to the readme alerting users to be careful when editing these options, since they were no longer changing all configurations, but just the current configuration. This change also applied to the version field, which could now be different between debug and release builds. At this time, we could have allowed auto-increment to work for debug builds too, since it would no longer interfere with the release version number, but for the sake of not changing existing behavior unless it was absolutely necessary, we decided to continue not supporting auto-increment for debug builds. Users can still change their debug version number to whatever they chose, but it continues not incrementing with each build.

2) This is what I was talking about earlier when I was explaining the purpose of dimming. The values are different, but CVI can only show one, hence it picks one, and dims the value text -- as a visual indicator that it's not the same value for all configurations. Just like in the example of the numeric controls that I gave earlier. This only affects what you see when you first display the dialog. You can still change it, and the change will apply to all configurations.

3) This is probably happening because the name of your program, under the 64-bit configuration, is still MyEarlierProgram. In the Target Settings dialog, cycle through the configuration ring while looking at the application file name. Is it really the same for all configurations? If it's not, then you'd expect %basename (and %filename) to appear differently when you preview the Version Info dialog. %basename is not version-dependent, as you said. It's configuration-dependent.

Luis

[Wolfgang]

Thanks again, Luis!

With respect to my sentence 'So %basename also seems to be version dependent', this was a typo and should have read 'So %basename also seems to be configuration dependent', so we agree