The wait for the long-awaited Yukon and Whidbey is going to be longer still, eWEEK.com has learned. Microsoft Corp. Director of Product Management for SQL Server Tom Rizzo confirmed that Microsoft expects to ship both Yukon—Microsoft’s code name for the next major update of its SQL Server database—and Whidbey—the coming update of Visual Studio—in the first half of 2005.
Yukon, Whidbey Releases Slip Yet Again
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I wonder by how many years Longhorn will be delayed. Latest estimates say it won’t be here until 2006… Who’s bidding on 2007 now that Yukon and Whidbey and other subsystems are delayed ?
At least some of this delay is due to them starting to take security seriously, so perhaps it is a good thing so when Yukon, Whidbey and Longhorn arrive they will have security added as more than a marketing exercise and Windows will be a bit less of a viral swamp.
I agree with Omega while Yukon and Whidbey arn’t strickly speaking required for Longhorn (WinFS will probably include elements of SQLServer to give its meta data searching abilities that are to be overlayed on NTFS, but probably not the whole thing) a slip to 2007 is looking rather likely. This could give them some problems with the SA licencing scheme as the guaranteed updates that this licence promised have delivered 0 updates on the major products and so looks like a bit of a waste of money.
At least some of this delay is due to them starting to take security seriously, so perhaps it is a good thing so when Yukon, Whidbey and Longhorn arrive they will have security added as more than a marketing exercise and Windows will be a bit less of a viral swamp.
On Windows being a viral swamp, I think it is more to do with the fact that almost every other desktop user is a Windows user and thus a much easier and better target for virus hackers. And as for the delay being solely for security, I have my doubts – no major Microsoft release have not been without its delays. Look at Windows 95, whose release is relatively minor in comparison with Longhorn. It was originally planned for 1992/3.
I agree with Omega while Yukon and Whidbey arn’t strickly speaking required for Longhorn (WinFS will probably include elements of SQLServer to give its meta data searching abilities that are to be overlayed on NTFS, but probably not the whole thing) a slip to 2007 is looking rather likely.
Actually, WinFS is based on Yukon.
Is this linux’s big shot? MS’s platform is, right now, pretty mediocre. Since .Net, not much has happened. So now linux has 1 year to play before anything interesting comes out of MS again. I wonder what it’ll do with the time?
As far as I’m concerned they can keep longhorn until A) a win2k service pack brings the security they are claiming for XP and Longhorn, and B) they get rid of those absolutely insanely ridiculously huge toolbars in Longhorn.
In the meantime, various high-level features that would have made Yukon a compelling competitor to enterprise-class databases—i.e., IBM DB2 and Oracle—have been cut. These include, according to Burton, clustering, hash partitioning, the use of Yukon as a unifying storage engine with Microsoft applications and file system support within the database management system.
Does this mean that the feard filesystem/OS merger, such that you couldn’t mount a volume without booting Windows, isn’t going to happen? I guess, even if it did, it would still have to mount legacy volumes, so there is some hope of interoperability…
One of the tenets of open source, “release early, release often”, is what I am thinking after reading the article. Rizzo talks about what customers want:
“If you look at Oracle [Corp.] and IBM and other competitors in the open-source space, they don’t have releases where new and innovative tools are released with a new and innovative database. Customers want that: the next generation of tools that exploit the next generation of database technology.“
Here, be basically says that they are innovating, and that they will be packing Yukon with all new features. Not just new features, but entirely new technologies.
Continue on with the article, and you get the following:
Besides, customers don’t want to spend any more of their time installing major new releases of database software than is absolutely necessary, Foote pointed out. “It’s disruptive of the business,” he wrote. “E.g., downtime for installation/upgrading, development modifications to take advantages of new database features, etc.
Obviously, Yukon is a major release. And in this release, you have a major shift in the way things are done. They aren’t just releasing a new server, they are releasing a new way of doing things. This is going to mean a major shift in how things are done, and hence, developers will have to train quite a bit to be able to use all the new tools.
How does this all relate to the “release early, release often” mantra? I find that with several smaller increments towards a complete release, it allows the customer (meaning the developer) more time to adjust to the new features. So if from version 2 to 3, you have, let’s say, 5 releases (2.2, 2.4, 2.6, and 2.8), you have a clear direction of what 3.0 will bring. Rather than moving from 2.0 to 3.0, and suddenly have to deal with many new ways of doing things, going with incremental releases allows you to slowly adjust.
Sure, in release 2.2 or 2.6 you might not get the new features, but then they will come in let’s say 2.4 or 2.8.
Something interesting is that Microsoft could have done this if they wanted.
But according to Enswers’ Foote, the most important items on the Yukon wish list aren’t such enterprise-level features. Rather, they’re run-of-the-mill tweaks that Microsoft could have added to SQL Server with incremental functionality updates over the course of the past few years.
And…
All of these examples and more could be implemented in existing products with existing class libraries that Microsoft already provides, Foote said. “SQL Server customers would be a lot more likely to renew their maintenance contracts if they had been receiving even incremental updates over the past several years,” he wrote.
The other interesting part is you will practically have to upgrade, and upgrade fast:
Another sore spot for users: What will Microsoft do with regard to continued support of SQL Server 7 and SQL Server 2000? Mainstream support for both is scheduled to end on Dec. 31, 2005, Alliegro noted. “That doesn’t give you a lot of time to upgrade [to Yukon],” he said.
Remember, Yukon is scheduled for release in the early HALF of 2005 (not first quarter, first half).
Anyways…just thought the article was rather interesting, despite not being an SQL Server customer/user.
Ok….is this year really going to be the year for linux……lol….I have been hearing this since 95′
Maybe one of these years it will actually happen……but for some reason I don’t think it will be before longhorn.
I am waiting for generics and iterators for C#. MS SQL server does not interest me one bit. Why are two completely unrelated technologies (The .NET runtime and C# / MS SQL Server) released at the same time. It does not make any sense except if they add features to .NET especially for MS SQL Server..
Anyway, probably mono will have generics and iterators faster than MS.NET. Now all they need is a good garbage collector.
Is this linux’s big shot?
In one word, no. Even if they don’t release another XP upgrade (besides SP2), the fact that the platform will remain stagnent doesn’t mean that the apps will, and apps are like 95% of the Windows appeal. The release date for Longhorn is really irrevalent, unless Linux can come up with something truly groundbreaking, in which case Longhorn will still be irrevalent even if it’s released next year.
He he.. Good old Microsoft.. Looks like my gamble paid off, by not renewing my MSDN subscription last month. I thought the cutoff date was a bit too close for MS to actually deliver on time..
The new Visual Studio releases are the only products from MS that I’ve actually found worth the money. And this is coming from a strictly C and C++ developer perspective.
I am waiting for generics and iterators for C#. MS SQL server does not interest me one bit. Why are two completely unrelated technologies (The .NET runtime and C# / MS SQL Server) released at the same time. It does not make any sense except if they add features to .NET especially for MS SQL Server..
When they’re discussing Whidbey, it’s primarily the IDE they’re talking about, not the runtime. The IDE has a good number of ties to SQL Server for those who use it with their programs, so it makes some sense to coordinate releases. I’m sure the runtime will also need some updates in ADO.Net to interface with Yukon. For many developers, especially working in support of an office environment, the database and the code may be seperate entities, but they are most definitely related, and sometimes nearly equal in importance.
how cruel waiting another year for generics…
This is good for Mono if the delay of Whidbey means the delay of .NET v.2.0(which I think it probably does). This gives Mono at least another year to play catchup and probably overtake .NET on things like generics(which Mono has preliminary support for). Heck, they might even have winforms done by then
.
If Novell could pump some resources into MonoDevelop(just hiring one full time developer would be great), you could even see Gnome have a very nice IDE for not just c#, but c/c++ and other languages as well by the time Whidbey comes out.
Yes, they will certainly have to update ADO.NET for Yukon. But ADO.NET is not a central part of the framework. It is just another library. They should release the core framework now (assuming that it is ready) and make a point release when yukon is ready.
This is one thing they could learn from open source: release stuff when it is ready, not earlier and not later.
Well. At least I can try out generics under mono using the experimental generics branch. Maybe microsoft programmers will take a look at mono since as of now it is the only way to get to know generics…
“Even if they don’t release another XP upgrade (besides SP2), the fact that the platform will remain stagnent doesn’t mean that the apps will, and apps are like 95% of the Windows appeal. The release date for Longhorn is really irrevalent”
I do think that this will be the year of Linux on the desktop. Just not the mainstream consumer desktop. Many Software Assurance liscenses are going to be running out for companies and many of them are going to be quite pissed off once they realize that they bought that liscense for nothing. We are already seeing many big name companies and governments replacing Windows with Linux: IBM, city of Munich, Rome, etc… Once secretaries and average office workers start using Linux everyday for work, they are going to start using at home because that is what they are familiar with. Also with companies like id, Epic, and now Macromedia looking to port apps to Linux, it looks like a great year for Linux on the desktop.
Longhorn might not be out till 2008 by some estimates, and now with Whidbey and Yukon being delayed for another year, it seems like all the new innovations are coming on the Linux front. Couple that with IBM, Novell, Sun, China, and the US Government all backing Linux it makes a strong statement.
Does the Software Assurance licenses count only for operating systems or apps as well? If it includes apps, my thinking is that many companies are more concerned about getting access to the latest versions of Office than Windows itself. Even as far as Windows goes, server 2003 was released recently, so it’s not like we haven’t had an upgrade since 2001 when XP came out.
Besides, having to upgrade a bunch of desktops to the newest OS can be a real pain in the ass, so assuming that XP SP2 relieves some of the security nightmares, perhaps it’s a *GOOD* thing that Longhorn is so far away?
Yes, they will certainly have to update ADO.NET for Yukon. But ADO.NET is not a central part of the framework. It is just another library. They should release the core framework now (assuming that it is ready) and make a point release when yukon is ready.
Again, though, Whidbey isn’t the framework, it’s the IDE. For a large percentage of their customers, there’s no point in them releasing the IDE without support for Yukon, and in comparison to the number of people waiting for generics support in C#, I’d have to say ADO.Net is a much larger portion of the update.
This is one thing they could learn from open source: release stuff when it is ready, not earlier and not later.
Sometimes people need to learn that something is not ready just because 90% of it is ready. People complain about Microsoft’s software needing so many patches and fixes, and then they complain about the software being delayed. The real fact of the matter is that ADO.Net probably works just as well as anything else updated in the 2.0 framework, but Yukon and Whidbey simply aren’t ready yet, or are not finished testing yet. MS’ website has 6 major features listed for Whidbey, and Yukon is one of them, while generics falls under “language innovation” or “.Net Framework Enhancements”. Additionally, Whidbey is supposed to “[enable] developers to write stored procedures using managed code” as part of its “deep support for SQL Server code name “Yukon””.
Of course, it would be nice if Microsoft released incremental updates to the framework and the existing IDE to support the new features that will be added to C#, VB, J#, and C++, but we all know that MS would rather get their $50 upgrade from as many people as possible (and the later more expensive upgrade, both assuming they follow the same strategy as the 2003 release) by releasing as many new features as possible at one time. Something else to consider is that they’re waiting for completion of standardization of C++/CLI through ECMA, though that has no effect on the use of generics in C#.