Fixes in ChemFinder Version Scheme
Jim Dill 18 Mar 02
The ChemFinder 7.0.2 splash screen and about box used to say "7.0.2" for the program version, instead of something more useful to testers like "7.0.2d453." It looked like all it would take to fix this was a change of one string, but that change caused another problem (see CSBR-28254) in which the first time you run 7.0.2 you are prompted for new registration info.
It turns out we have a lot of fuzzy thinking and baggage code in the handling of version info. The scheme needs to be revamped for CFW8. Proposed design will be outlined below, sooner or later.
Places where the version matters:
|where||what we want||handled by|
|Splash screen||Pro 7.0.2d453||cfw\splash.cpp, CVersion::SplashVer()|
|About box||Version 7.0.2d453||cfw\cfaboutbox.cpp, CVersion::ProgramVersion()|
|Explorer file props||220.127.116.113||iolib\iolib.rc2, version info resource|
|CS registration||7.0||iolib\reg_cfw.cpp, CVersion::ProgNameForRegistration()|
To be revised. We intend to make this better for 7.0.2.
Splash screen and about box will say "7.0.2" only. The build number can be seen in Windows Explorer (but it will say 18.104.22.1683, not 22.214.171.1243). Registration info will be the same as for 7.0.
To test: on a machine which has ChemFinder 7.0 or 7.1 installed, replace cfw.exe with 7.0.2. On startup, it should NOT prompt for registration info.
Some of the requirements for a new design:
Olson's Proposal for Program Versioning
Mark's reply to a message from Jim:
Do we have a standard policy regarding what should be displayed in splash screen and about box? Installed ChemDraw displays "7.0.1d4" where ChemFinder says "7.0.1" and CF Word says "7.0". Question 1. Is "4" the ChemDraw build number?
Yes. It grows monotonically throughout the 7.0.1 development and release process. It need not start at 1, be dense on the integers, or grow by any particular increment, though people have an expectation that it grows by 1.
2. What's the "d" for, and does it ever change or go away?
"Development". It used to change to an "a" for Alpha, a "b" for Beta, an "fc" for Final Candidate and go away (along with the build number) for release, but since we can't presently change it without a build, we've not been bothering and have used 7.0.1dnnn right up to release.
3. Is this policy written down anywhere?
Not that I know of, nor is it universal. Perhaps we should consider doing so!
What I think I want to see is something like this:
Versions of programs are labeled a.b.cLnnn, where a, b, c, and nnn are integers, and L is a letter.
"A" is the main version number and increments only when there is a major new release.
"B" is a sub version number and distinguishes minor releases containing new features which do not qualify for incrementing "a". Whether a particular release increments a or b is a marketing decision.
"C" is a bug-fix version number and is incremented when a bug-fix version is released.
When "c" is zero, it is dropped. When "b" is zero it is retained. (I.e., we write 7.0d345 and 7.1d567, not 7.0.0d345 or 7d345 or 7.1.0d567.)
"Released" in this sense implies something more than "released to testing" and something less than "released to volume shipment in boxes on CD". My inclination is to use it for release to multiple customers by CD or by putting it in the store or by giving it to Support for distribution.
Released versions do not have the Lnnn part of the number on the splash screen, but retain the nnn part in the .exe's properties.
"L" is always "d".
"nnn" increments continuously and is reset to 1 only when "a" changes.
There is a lot of benefit to having nnn reflect a particular night's build and be the same on all executables, but it's non-trivial work to keep it in sync, and I'm not completely convinced it's worth the trouble. But probably it is.