>>OK, but I'm talking about bugs here that may exist in your code. If a user is banging away but can't get what he expects he should get, he'll be pissed too if it's the result of a bug. But give him a place to go to learn what may not work quite as advertised at this time and he won't even give it a go in the first place. Or he'll check early, saving tons of aggrevation.
>
>I think we're discussing about two different things. I'm talking about Full Disclosure (all details, plus explotation code) of security and privacy bugs. Is this what you're talking about?

No, not security and privacy but bugs in general.

When you resumed this you had quoted (and replied):
">The IIS issue may be a great point, but VFP ain't IIS and there are no CodeRed-like worries with VFP!

Why not? There are times when security risks in VFP itself can be threatening, or security risks exclusive to my product can be threatening, in both cases, I think that Full Disclosure would be as bad as it is with IIS."
---- end of pasted

I had said that I agreed that full disclosure could be a problem for security/privacy stuff, particularly for WEB stuff (I.e. IIS and such).
Should there be similar deficiencies in VFP then I could go along with keeping mum about them provided that all other VFP bugs were full disclosed in a timely manner.