The CTP Process
How is the CTP process working? Ive heard complaints that there are too many CTP releases and things are becoming confusing for testers and leading them to be less thorough. What are you hearing from developers on this? Somasegar: We consistently receive very positive feedback on the CTP programdevelopers tell us every day they love the frequent code drops so they can monitor progress were making on VS 2005. Developers love this level of transparency and are feeling more like an extension of the VS development team as a result of the CTP program.But its critical for testers to also understand that VS CTPs are intended to only provide a snapshot of progress at interim junctures of the product development cycle. Developers should decide how much time they want to spend on each CTP release. We do love the feedback that we get from developers on our CTP drops, and that absolutely helps us build the right product. If there is something new or they care about a particular feature/bug that is fixed in a CTP release, by all means they should pick up the CTP and give it a test drive. On the other hand, depending on what a particular CTP includes, some developers may choose to just give a cursory look at that. We dont expect every developer to go deep every time we release a CTP.The changes in Longhorn announced in the fall, how will they affect Orcas? Somasegar: The previous plan of record, before we made all the changes, was that we would ship Longhorn and then we would have a tool set called Orcas that would target that system. Nonetheless, we also said, in the old plan of record, that if a developer wanted to develop a Longhorn application using the new managed interfaces and the like, you do not need to wait for Orcas. What you can do is take the Whidbey or Visual Studio 2005 tool set, and you can start writing a program using the Longhorn SDKthats a Longhorn application taking advantage of the new managed interfaces, and that application will run on Longhorn. The things we are missing in Visual Studio 2005 are some specific designers targeted at the Longhorn components, namely Avalon and Indigo and the like. But to be able to write code, you can get started on that with Visual Studio 2005. So that is the old plan. Now the changes that we announced in Longhorn in my mind, if I had to summarize, there are about two or three changes that we announced that are meaningful changes. One is we said we are going to do whatever it takes for us to have a high confidence plan of delivering a very quality Longhorn in calendar 2006, so that if we have to cut features well cut features, if we have to do something else well do something else. But it is super-critical because we think there is so much value that we think we can deliver to our customers that we really want to get into a plan that will let us deliver Longhorn. That is one thing that we announced. The second thing that we announced was if you think about WinFX as sort of the next-generation API layer that we want developers to target there were three components that we talked about before: Avalon, Indigo and WinFS. What we said was the feedback that wed been getting from our customers was its great that Longhorn is going to be this great, new platform, but hundreds of millions of installed base customers arent on Longhorn, and if you tell me that my Longhorn application runs only on the latest and greatest hardware, then I have a problem because I really want the reach. Reach has always been an important thing for ISVs of the world. And for a while we were thinking that Longhorn is so great that everybody will just get that. So we took this opportunity to say that Avalon and Indigo, when we deliver the first version of that in the Longhorn time frame, those things will not just run on Longhorn, but also run on Windows XP and Windows Server 2003, so that we really have a solution for the reach issue that ISVs have. That was the second thing we announced. The third thing we announced was the third pillar of WinFX, which is WinFS, the new file system and storage system, we said that will not be ready in the year 2006. We said if you want to be realistic about it, we think it will take until 2007. And so we really had two options. One was to say were going to slide everything until 2007 and wait until WinFS gets ready so we can ship it all at one time. Or we said we had the option of saying that WinFS will be delayed until 2007, but I can get everything else done in 2006, and not only that, I can get Avalon and Indigo to support down-level systems as well. And obviously the latter plan looked more interesting for our customers and for us, so we went with that. So in the new plan, from a tool set perspective, its pretty much the same. Whidbey is the tool set you want to use to start building Longhorn applications. You can start with the Whidbey beta and Longhorn SDK. If you want to wait until Whidbey RTM, thats fine too, but Whidbey is the tool set you want to get started on. The next version of the tool set, which we are internally calling Orcas, will still contain the new designers that we want to have in place for some of the Longhorn components. But beyond that it doesnt fundamentally change us. Well still shipping Whidbey this year, and then well turn around and do an update with Orcas that fundamentally is Whidbey, but includes some new designers and some other things. And we are still in the early phases with Orcas. So Orcas was originally planned for release in 2006? Somasegar: We always said it was Longhorn plus probably three to six months. That is it would be part of the Longhorn wave. And in the new plan, Orcas is still part of the Longhorn wave. Next Page: Release plans for the Microsoft Business Framework.