Build Numbers
Mike Blaszczak -- mikeblas@nwlink.com
Friday, January 10, 1997
At 10:47 1/9/97 -0500, Dave Kolb wrote:
>My msdev\mfc\src\build_.h has version 6139.
For which version?
>mfc42.dll that has version 6256 and a mfc42d.dll that has version 6269
>in that directory.
Maybe I'm misremembering the numbers. I'll check at work sometime next
week and post a list of the build numbers that we've dropped for
the 4.x versions. (It's really moot, though: you should install a
newer one over an older one, and that's that.)
>Should the release and debug be different versions after the patch?
The build number is the date of the build. It's conceivable that the
retail build was done on a different day than the debug build. The
build number doesn't reflect the day that source code was checked into
version control, or the day that the product appeared on the web site
or began shipping or started showing up on store shelves. As such,
the build number is only loosely related to a bug fix. If I check
in a bug fix today (which is 7010) , it _may_ show up in build 7011,
but it certainly won't be in build 7009. But it might not appear
until build 7014.
>If version number relates
>to the date of development then I'd think this is very important to
>make sure things like patches and fixes you made are actually
>included.
The build date really doesn't mean anything. If you were working
on the team and seeing a few builds every week, it would be more
important. Sometimes, in a beta, the build number is important so
you can clearly identify exactly when the bits for a particular beta
drop were cut. But since only certain builds are actually released,
and each released build gets a new version number.
So it's much more convenient, in almost all cases, to identify a
given installation by theversion number than the build number:
I'm _on_ the development team, and I can't even perfectly remember which
build number had which fixes, but I can recollect most of the fixes
I made before a particular version number was made. It's hard for me
to understand how folks off the team would relate a particular
bug fix to a build number that they'd never, ever see, anyway.
Dave Kolb -- sasdxk@wnt.sas.com
Monday, January 13, 1997
...
So it's much more convenient, in almost all cases, to identify a
given installation by theversion number than the build number:
I'm _on_ the development team, and I can't even perfectly remember
which
build number had which fixes, but I can recollect most of the fixes
I made before a particular version number was made. It's hard for me
to understand how folks off the team would relate a particular
bug fix to a build number that they'd never, ever see, anyway.
I don't think the value is to relate a bug fix to a build number; not
by the customer anyway. One good reason for us to supply the build
number though is to tell if someone is actually using the version of
the mfc42.dll that they say they are because perhaps the patch failed
or the dll already got updated. I.E. they are actually using either
the original, patched or a newer product or OS version but thinking
and saying they are using 4.2b since they went thru the mechanics of
putting the patch on and didn't realize it did not take or later got
replaced.
For instance, I put the patch on successfully, upgrade to Office 97
and a week later have a problem. I say I'm using 4.2b in the problem
description but actually have a newer version. Yes the newer version
has all the bug fixes in 4.2b but let's say the newer dll introduces a
new problem that is similar to a problem that was in the original
non-patched release that you know was fixed in 4.2b which I said I was
using.
In any event, the various "released" build numbers would be nice to
know.
Thanks,
Mike Blaszczak -- mikeblas@nwlink.com
Wednesday, January 15, 1997
[Moderator's note: Is this supposed to be on this list?]
At 09:47 1/13/97 -0500, Dave Kolb wrote:
>One good reason for us to supply the build
>number though is to tell if someone is actually using the version of
>the mfc42.dll that they say they are because perhaps the patch failed
>or the dll already got updated.
Maybe they should post CRC and checksum values as well.
>For instance, I put the patch on successfully, upgrade to Office 97
>and a week later have a problem. I say I'm using 4.2b in the problem
>description but actually have a newer version.
If you work with PSS, they'll probably ask you to run one of their
tools to dump the full version numbers for _all_ of the loaded DLLs.
You might have a goofy build of OLEAUT32.DLL, for exmaple, and that
could be what's really causing your problem.
In formal support situations, that's a reasonable idea. Here on
MFC-L, I doubt David would be interested in validating all that
information... and I already say "you're not providing enough
background information" too often, anyway.
.B ekiM
http://www.nwlink.com/~mikeblas/
Why does the "new" Corvette look like a 1993 RX-7?
These words are my own. I do not speak on behalf of Microsoft.
| Вернуться в корень Архива
|