>>I too am bothered that there is no up-to-date bug list available to the public for any VFP version. Even more bothered that the keepers of the UT will not accommodate one!
>>
>>But I'd say that 1 critical bug is enough to justify a SP and that in such a case then all previously reported bugs that have been confirmed and fixed and tested should be included in that SP.
>>
>
>How do you define critical? What may be critical to you may not be to 10,000 others.

We'll probably never agree on what is "critical", Craig, because your view is always too slanted towards MS (as is evidenced by your contributions to this thread alone).

I'd classify the inability to use FOR...EACH under all circumstances with the new Collections class as critical, even though FOR...NEXT is a workaround. Why? Because it is a brand new feature and it damned well ought to work in it's most logical prescribed way from the start.

I'd classify the inability to access array elements beyond 4096 (first column) when the array is a property and 2-dimensioned as critical even if such is presently used by less than .1% of the VFP developer population. There is NO (known at this time) workaround for this.

I'd classify the fact that SET TABLEVALIDATE TO's record count check being done AFTER the write (INSERT or APPEND) as critical because the purportation (like that word?) that it fixes the lost records problem is FALSE because of that!!!

My guess is that you'd classify any of these otherwise, and I'd say that you would be wrong in doing so.
Any reported "bug", even the trivial ones with easy workarounds, deters some people from adopting VFPx, and the VFP Team can ill-afford even one person's decision to remain at a prior version at this time.