Mike,

SNIP
>
>>Service Packs are intended to make the product what it was originally intended to be: a technical and sales success.
>
>Service Packs are intended to make a product useable and stable. There is a very big differnce. The reality of developing and deploying features for free was outlined in my last message.

I think Mr. Allen did come up with a very legitimate observation that a Service Pack is also a marketing tool. As he said, some management (quite a few, I'd hazard) simply will not install the .0 of any product into production. So a timely SP1 should at the very least assist the sales volume for VFP. And lord knows that enough bugs have been identified here alone to warrant a SP1 ASAP!

There is no doubt that new functionality was introduced in VFP6 SP3. In addition to what JVP listed, I think run-time compiling came in that one too. There may have been more.

I can see both sides of the argument on this one - especially the one about where do you cut things off to make a whole new release.

Being a user/developer with VFP I opt for adding functionality within SPs. It's been done before with great benefit, so it's nothing new.
The Toledo Wish list here alone lists over 150 ideas for improvements to VFP, covering the gamut of areas Mr. Allen used. Not to mention, of course, the thousands that are already in the hands of the VFP Team from prior years and from other sources. Surely they could spend a little time "weighing" some of these for inclusion in a SP or two.

Cheers,
Jim