It would still be useful to define for each field whether or not it's a number, so the auto incremementing still works.
Also, an I8 seems like a very limited choice. I would say it should be at least a U8, if not U16. I may not run through versions that fast, but it's nice to have the option. I certainly do have executables which are updated with minor features and bugfixes relatively often.
I agree that I8 is an unnecessary limitation, however I really hope that they stick to numbers. We should all adhere to a standard here to make it understandable for everyone how different versions relate to eachother etc. Allowing a string input will result in a mess.
Using the year as a version number is a weak (marketing based) idea. I think the feedback to NI when they introduced LV2009 showed a consensus about that. On the other hand I can understand why others will follow when that's what users get used to, but please - just put it in the name of the application, not the version number.
I agree that I8 is an unnecessary limitation, however I really hope that they stick to numbers. We should all adhere to a standard here to make it understandable for everyone how different versions relate to eachother etc. Allowing a string input will result in a mess.
National Instruments doesn't even adhere to that standard. For example, I'm running LabVIEW 8.6.1f1
I doubt that you are actually running 8.6.1f1, does the version number of the executable mention 8.6.f1 as well? (it's in the properties page of the executable file), my executable file version is 8.6.0.4001 for LabVIEW 8.6.1:
This means the major version is 8, minor 6, bug 0 and build 4001
The build number you can set in a executable builder is shown here.
The number Crelf mentions is set in the application builder and is used by Windows to determine whether the application needs to be upgraded. Allowing non-numerics into the version is a nightmare for comparison. What is bigger: 4.1a or 4.a1 or 4.A1 or 4.1A?
