[<<]Message[>>] [<<]Author[>>] [<<]Subject Thread
Number : 2806 Date : 2002-09-15 Author : Kan Yabumoto Subject : Re: Digest Number 422 Size(KB) : 3
Jon: Thank you for your suggestion. Once upon a time, many programs had a single digit version number. Then came two digits with a decimal point in between. When IBM-PC was born, the industry was already with three digits. I'm just looking at an old 5.25" floppy disk from IBM; the label says IBM DOS Version 1.00. We pretty much follow this scheme. So, really we are talking about XXCOPY version 2.83. Any new release is supposed to be a clean number like 2.80, 2.90. and so on. The last digit in our four-digit system was designed to allow us to make a small change which are a result of some minor bug fixes, etc. On January 1, 2002, we released a new version 2.80.0 which we hoped to be stable for some time. But, within a week, we had 2.80.1, 2.80.2 and then the version number was 2.80.3. In retrospect, it became our lasting version for some time. From our point of view, we wanted 2.80.0 to last. By the time we had the version 2.80.3 out, we did not know whether this or the next version would be a lasting one... I'm sure Microsoft (and everyone else) has similar headache. The Visual C++ compiler package that we have been using for a long time had version 6.00. But, we know they released many different versions under the same number. Alas, the real identity is in the four extra digits beyond the version number. And, the current official release of the same product (now, they call it Visual Studio .NET) Version 7.00. Actually, Microsoft's C development packages for Win32 environment went from 2.00, 4.00, 5.00, 6.00 and now, 7.00. Then apparently gave up using the 2nd and 3rd digit which are predictably always 00. That is quite silly. We should stick to our original plan in the version numbering. That is, the first three digits should characterize what it is. The last digit is for just in case we made a small mistake and needed to release a corrected version. One way or another, we have to use all four digits to identify the version for the purpose of bug report and so on. We tend to be stingy on the version number when we are incrementally adding features and fixing bugs on as-needed basis. But, we should not be stingy on jumping to a clean number when we have a bigger releases. (Alas, we don't have time and resource to hold smaller releases and make less frequent big releases). While less frequent releases helps many users from bothering frequent update chores, many users do not want to live with known bugs even if we describe the nature of the bugs. So, we will continue to use the two-tier approach: http://www.xxcopy.com/ http://www.xxcopy.com/betatest/ ====================================================== So, as my response to Jon's suggestion, I really don't think adding another digit will solve anything. We already have more digits than we really need. It's that we have to be consistent and predictable in assigning the number. And, the very latest release was our mistake calling it rather inconsistently to XXCOPY's recent release history. When we move the version from the betatest site to the home page, we will reassign a more consistent version number (and we will make clear that it is the same as v.2.82.4 so that those who already have it would not waste their time downloading it again). As to using an LFN, we old-timers avoid an LFN at all costs. Kan Yabumoto ========================================================== At 2002-09-15 14:19, you wrote: >Why not v.2.82.3.1 for a version localized to v.2.82.3. Of course then >your file >names would need adjustment to allowing 5 chars for the version >number. You could >also use lfn instead of sfn, at least for the downloaded version.
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.