Hi Jose,

From my developer's experience, I think I would approach your situation this way: Develop your application using VFP 7 but architect so that you can retrofit desired VFP 8 features into your application. Remember, you have the VERSION() function to trap the VFP version - you can always code to both but block VFP 8 features based on VERSION().

To me, this is a safe (but perhaps not optimal) approach. Yes, I realize it's limiting insofar as using the coolest features of VFP 8 or actually writing a solely VFP 8 application.

OTOH, if you can deliver a bullet-proof application to the users using the existing, public technology (VFP 7), that may give you the mandate to retrofit VFP 8 features in an update.

A rule of thumb is to never deliver on promises; deliver on solutions. As much as I love VFP 8 and think it's the greatest version of VFP since VFP 3, I wouldn't advise you to "bet the farm" on a beta. Behaviors may change or features may be added or dropped ... these are issues you have to avoid in the short-term.

In the long-term, you know that you'll have these cool features (even if they change between beta and release) and you can plan accordingly. Give the customer what they need in the short-term and you can sell the long-term thereafter.

Make sense?


>>Hi Jose,
>>
>>Why would you have problems? Surely you don't distribute applicatiosn based on beta software? ;-)
>
>No, I don´t distribute applications, but I have some internal application I have to finish near March, and I was thinking to begin with VFP8, but this change my plan, because first quarter finish 3/31 and Beta finish 1/31. I think my product could wait some weeks if VFP8 don´t release in first quarter (surelly my don´t need VFP relese delay for delay itself ;-D) , but I need all first quarter for develop it.
>
>I begin with VFP7 SP1.
>
>José Luis.