Well, the road map is up and it says ......
"The primary goal of Sedna is to expand on the ability of Visual FoxPro-based solutions to better integrate with other Microsoft products and technologies."
Hmmm....what that mean? Well it certainly states what it does NOT mean:
"Microsoft does not plan to merge Visual FoxPro into Visual Studio .NET, nor are there plans to create a new Visual FoxPro .NET programming language."
The one I wish they would do is bring back the ability to debug FoxPro in Visual Studio but I think debugging COM components is something that every developer wants an easier way to do, and because of the very nature of COM, it's very difficult to do.
But the real focus is noted in Ken's June letter, where he effectively says they are working less on specific language or engine features and more to ensure FoxPro apps will run well in 5+ years. In short, maintenance mode.
Which is GREAT news for developers who are tired of constantly having to upgrade to the latest version, but NOT SO GREAT for those of us who are looking for more features to be put into the core engine. Developers should be fairly happy that while development has not STOPPED on newer tools for use within FoxPro, they should be able to work with a single version for a period of longer than two years. New features and tools will be made available - and they will WORK with the current version, not requiring endless upgrades.
However, if you look at many of the features to be found on the Wiki's Version 10 Wish List, you can be sure that some of these requests will find their way into the xBase apps or C libraries that will make up much of Sedna.
I'm sure some will take this "map" to mean all kinds of horrid things but the fact is that Visual FoxPro is a very functional language and database tool. I just finished a discussion with a client where we were talking about roadmaps. As a statement of what the Fox team is doing or will be doing for the next x months, the roadmap is good. As a true roadmap, one that shows where FoxPro is heading, this one is sorely lacking and open to many different interpretations. Granted, Microsoft has to be careful of not setting off too many on the everything is dead trail as they did with the VB 6 community - but something a little more would have been appreciated.
As it stands now, FoxPro developers should take great comfort knowing that VFP is supported in its current form by Microsoft until 2014, a full nine years away. By that time, DotNet could be replaced by yet another acronym (how quickly did it take MS to move from ActiveX -> COM -> DNA -> DotNet). Maybe in 9 years time, it will translate itself into another one of Microsoft's OpenSource projects.
On a slightly different note - if you're working with VFP and DotNet, Kevin McNeish's book DotNet for VFP Developers is available for download. That's good news for many people who need to switch back and forth.
Visual FoxPro: Microsoft Visual FoxPro Roadmap
"The primary goal of Sedna is to expand on the ability of Visual FoxPro-based solutions to better integrate with other Microsoft products and technologies."
Hmmm....what that mean? Well it certainly states what it does NOT mean:
"Microsoft does not plan to merge Visual FoxPro into Visual Studio .NET, nor are there plans to create a new Visual FoxPro .NET programming language."
The one I wish they would do is bring back the ability to debug FoxPro in Visual Studio but I think debugging COM components is something that every developer wants an easier way to do, and because of the very nature of COM, it's very difficult to do.
But the real focus is noted in Ken's June letter, where he effectively says they are working less on specific language or engine features and more to ensure FoxPro apps will run well in 5+ years. In short, maintenance mode.
Which is GREAT news for developers who are tired of constantly having to upgrade to the latest version, but NOT SO GREAT for those of us who are looking for more features to be put into the core engine. Developers should be fairly happy that while development has not STOPPED on newer tools for use within FoxPro, they should be able to work with a single version for a period of longer than two years. New features and tools will be made available - and they will WORK with the current version, not requiring endless upgrades.
However, if you look at many of the features to be found on the Wiki's Version 10 Wish List, you can be sure that some of these requests will find their way into the xBase apps or C libraries that will make up much of Sedna.
I'm sure some will take this "map" to mean all kinds of horrid things but the fact is that Visual FoxPro is a very functional language and database tool. I just finished a discussion with a client where we were talking about roadmaps. As a statement of what the Fox team is doing or will be doing for the next x months, the roadmap is good. As a true roadmap, one that shows where FoxPro is heading, this one is sorely lacking and open to many different interpretations. Granted, Microsoft has to be careful of not setting off too many on the everything is dead trail as they did with the VB 6 community - but something a little more would have been appreciated.
As it stands now, FoxPro developers should take great comfort knowing that VFP is supported in its current form by Microsoft until 2014, a full nine years away. By that time, DotNet could be replaced by yet another acronym (how quickly did it take MS to move from ActiveX -> COM -> DNA -> DotNet). Maybe in 9 years time, it will translate itself into another one of Microsoft's OpenSource projects.
On a slightly different note - if you're working with VFP and DotNet, Kevin McNeish's book DotNet for VFP Developers is available for download. That's good news for many people who need to switch back and forth.
Visual FoxPro: Microsoft Visual FoxPro Roadmap
Comments
Visual FoxPro to .Net