>Hoi Peter,
>
>>>>It's a thread meant to challenge the claim of MS about the 'MOST STABLE' thing. It's a constructive criticism I think.
>>>
>>>Well I think you have chosen a rather poor title for the thread, as I don't directly associate bugs with stability, and I think you do have the wrong idea of classifying bugs.
>>>
>>>If you started something like VFP9: the version with the most or least number of bugs, I would have agreed.
>>>
>>>Walter,
>>
>>What's in a title...
>
>>Besides, your statement that bugs and stability are not really associated can be challenged. The type of instability that Jess is talking about can well be (and often is) caused by INTERNAL bugs.
>
>Sure, but as others and I have outlined, bugs come in classifications: Roughly, bugs that result in unexpected outcome and bugs that causes your application to hang, produce a C5 or otherwise become non-responsive. The latter specify the stability of an application IMO. So I don't regard the number of bugs directly determine the stability.

How would you call a version that produces many wrong results in functions like sum, avg, strtran, left, etc., although it never crashes? I wouldn't want to argue with those who'd say it is an unstable version. For those who build critical (results of calculations MUST be okay) applications, it would be an unstable version. Your idea about when it's 'only a bug' and when it's unstable, can be challenged.

>>And another besides: The title doesn't mention the word 'bug' at all.
>
>No, the contents did.
>
>>Actually, when Jess refers to the supposedly poor way that vfp9 handles matrix printers, he need not talk about bugs at all. Rather, it is then about the design.
>
>If it was purely about design, he would not have questioned the stability of VFP9.
>
>>And when a matrix printer causes a crash or surprising outcome, I can imagine that a developer doubts the stability.
>
>Again, IMO, a crash decreases stability, unexpected outcome IMO, is a different matter.
>
>Walter,