Upgrades
-
Your question is a good one, but I think the question needs a little tweak. I think the question should be
"Should MS make a new release every 2-3 years or should MS release an addition/enhancement to the current product?"
You see, releasing SQL server every 2-3 years causes problems for DBA/Developers/Business because of dollars and building of knowledge. Once you get really good with 1 product it's time start from the beginning again. Don't believe me?? Just any DBA who was an expert in SQL 2000 and see where they are at today?
Personally I believe that the release for 2008 should be built on the exsisting SQL 2005. The UNIX world has been doing this for a very long time and you can see how stable it is. If MS would keep refining there product and release a new one every 5-7 years we would be more willing to upgrade. More DBA's I've talked to said they are not upgrade to 2005 from 2000 because they don't have the time or resources and that they may as well wait a bit longer.
Just my 2 cents worth
Rudy
-
Thanks for the replies and a couple of thoughts.
First, MS has typically done "two releases" of the same platform. 6.0/6.5 were essentially the same product. v7/2000 were really close. In fact, 2000 was shown at the first PASS Summit in 1999 as SQL Server 7.5. And from what I'm hearing about SQL Server 2008, it's essentially the same platform as 2005 with more features and things matured.
We could argue it should be a point release, but it's not going to be. It kind of reminds me of car sales. We see new models every year and they're not often changed. In fact, cars seem to run a similar 4-5 year cycle before they're redesigned.
And why is it last year's model, which was the best car ever last year, suddenly isn't worth looking at when you're at a dealer?
I can live with a new product every 2 years, but I'd like to see the old ones with GUARENTEED service packs, 2-4 a year. They've committed to regular rollups, so we'll see if that happens. However I'd also like to see 3 versions at least on each platform. Give us 6-9 years to really work with a product, upgrade skills, and let it mature.
-
Here's an idea - major releases every five years (with a point release after 2-3yrs if they need something to feed the marketers).
But the biggest thing I'd like, especially with something as fundamental to business operations as server software, would be a 10yr support plan.
-----------------
C8H10N4O2
-
In my opinion 5 years should be a good interval.
-it takes about 6 months after the release to get the first service pack, after that I start thinking of installing or upgrading in production
-it take months till you get resonable good documentation on the software - good book on SQL2k5 just started comming a couple of months ago
-after about 8 months of working with SQL2k5 I have the filling that I just scrached the surface, and in fact there where so many teams of people working on this product for several years, would be kind of surprising if somebody after 2 years can say that he knows the product not just a very specific portion of it
-
About those ongoing costs you mentioned - a lot of those can be minimized by "doing it right the first time." Back in the day I had to research some of these ongoing costs, and one thing that jumped out at me was the cost of fixing bugs in production code. This is a well-researched area, with the cost of fixing bugs estimated somewhere between 10 and 1,000 times the cost of doing it right the first time (yes, you read that right, 1,000 times!) These numbers come from studies conducted by IBM and various consulting companies.
So to expand your example, if one of those bugs in your software package would have cost $2 to avoid in the first place, it's going to cost between $20 and $2,000 to get the patch together, perform regression testing, distribute it to consumers, etc. after the fact. Even at the low end, you have to sell 2 more units of product just to break even after the bug fix. At the high end, you've wiped out all of your profits after just 2 bugs are discovered and fixed.
Personally I would like to see MS apply more thorough testing of their software up-front, resulting in fewer service packs and hot fixes in the back end. If that means I have to wait until 2009 for Katmai, then that's just fine with me.
-
We have usually done something different. When SQL2000 hit we waited about 8 months and put up a test environment. Once familiarized we mover support to production and stated that all new applications would be developed on 2000, unless there were integration or other issues that could not be solved quickly. Then over a 6 month period we migrated all the older applications to 2000.
A few lessons learned in that migration were recorded and before long SQL 2005 became available. The newer features were then and are now interesting to our data and development staff. So we followed the same process to a point. We installed a test environment for 2005 and ran the software through the paces. Once proven, Endpoint looked at, SSIS seen and a few of the other features being run by us and not the canned demo of the MS Sales staff we made a recommendation. Move SQL2005 into production for new applications.
Initially we only migrated one application. That was one of our central databases where we could use the new technology of SQL 2005 more. Thus we migrated one and have developed a dozen or more new 2005 systems already. Developers love it and we are not going back.
What about the older SQL 2000 systems? They are quietly running and we are currently discussing if there is or is not a business reason to move the entire collection to SQL 2005. Don’t know yet but as time ticks on we will be more and more tempted. When support runs out for 2000 in 2008 we will be either moved of will have determined the risks and have decides that migration could be postponed. Running without support is an interesting idea for many but in some cases it is necessary.
At this point we do not know if we will migrate the SQL 2000 systems to SQL 2005 or wait for 8. We will have to see what the business priorities are. But no matter, we will be addressing the standardization of the connection string practices sooner rather then later and determine a strategy that all applications will follow for config files, encryption and other issues that effect migration of the backend databases.
All that to say Microsoft can roll out a new version as frequently as they need to. We will migrate when and if the business dictates it. 2 years? 5 years? No matter, we control when we move, when we are driven and when we can afford to migrate.
Have a good day...
Not all gray hairs are Dinosaurs!
-
I think SQL 2000 was such a hot seller Microsoft did not want to rock the boat. But 5 years was just a little too long.
My vote 3-4 years for Databases and Server Applications. Given at least one year from intitial RC to Production Release.
2 years is fine for Client tools like Visual Studio.
Dan Collier MCDBA, MCSD.NET
-
I have read many interesting points and experiences thusfar and cannnot add anything that has not already been said. So we will get right to the point.
- Major release - every 5 years
- Dotted release - every 1 to 3 years
- Roll-ups - annually
- Support of releases
- Release n - 10 years full support from release month
- Release n-1 - 5 years partial support - after the initial 10 years
- Release n-2 - 5 years support of existing/documented issues only
It seems logical. Look ad some of the other relational DBMS players such as Sybase, Oracle and DB2. MS can certainly do us better.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
I agree with Rudy - especially re: the 10 years of full support.
How can any of us possibly become a true expert on any MS product with these short product life cycles?
-
I'm surprised to find so many Luddites in the database community, but I guess that shouldn't be a surprise to me. DBAs are the Department of Redundancy Department after all. Heh. Nobody cares what my opinion is on this (in or out of the mothership), but I'm going to drop it anyway. It's my own opinion and carries no warranty or weight whatsoever.
1. We need ANNUAL releases of the entire SQL Server suite.
2. We need monthly rollups of SQL Server hotfixes to Microsoft Update and client WUS servers.
3. We need to walk-the-walk with regards to incremental engineering.
4. We need slipstreamed hotfixes in the OTS product box in betwixt the annual releases.
5. We need to stop mass production of optical media and produce it JIT at order time.
This schedule will reinforce the new SQL engineering process and enforce automated unit test discipline.
I'm hoping that some of the new Katmai infrastructure will really enable the slipstreaming option. Nobody should be able to buy an unpatched version, IMNSHO, especially with regards to security fixes.I realize that the impossibility of getting all 1,000+ members of the SQL team dancing to the same tune on the same schedule makes what I want purest fantasy... but once you get used to a iterative, continuous integration lifestyle, it's smooth sailing.
I'm guessing that a lot of the "please don't upgrade me" crowd are glad that I'm not in charge of release management. I've met the guy who is, and he's got about as much hair left as I do. 
No victim of an evolutionary process likes the fact of evolution.
Upgrade or ...?
-
David,
Your schedule works great, for those of us whose only job duties are server upgrades. @=)
Though, I suppose if the products worked out of the box every time (or at least 99.9% of the time) MS released something, life wouldn't be so bad. But I don't have time to hot fix and patch and hot fix and upgrade and patch and hot fix 24/7. And honestly, who does?
-
You have all said it I think, but the upgrade cycle for all products should be 5 years in my opinion. That would give us time to learn the product, upgrade, and skip the next upgrade, so we would have a good 10 years to be using the same technology. Much faster causes more problems than it fixes:-)
-
Andy,
You have hit the main reason for most software problems people waiting for employer to upgrade their skills when education is each person's responsibility. Companies have no plans to pay for fast moving software education, employees rather go to Cancun than pay for needed education.
Kind regards,
Gift Peddie -
Put me down for 2.5 years.
It takes about 18 months to develop and thoroughly test new features. I want the developer teams at Microsoft to have a good year to benchmark, blackbox, do proof-of-concept and generally play with new ideas before that development cycle begins in earnest.
:{> Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
-
I'm for small incremental updates like they do in the Oracle world. The problem is that you can't roll out major new features and everything has to always be back-compatible. I always try to use the smallest and most-compatible subset of SQL, but I didn't like it when I had to re-write some code for SQL 2005. I also have apps that are running on SQL 2000 servers, and I want to take advantage of useful features of SQL 2005, and I would rather not know about them if I can't use them (sort of). This is confusing in the other direction too, because my dev server is SQL 2005 and my production server is version 2000, meaning sometimes I put code 'up' to production and it doesn't work because it has 2005-only features. Not that I actually do that, but it could happen.
I think that smaller and more frequent updates force a company to maintain better compatibility between versions, and I prefer compatibility at the expense of new features. Stability within the product line is way more important than new features I think.
Viewing 15 posts - 16 through 30 (of 39 total)
You must be logged in to reply to this topic. Login to reply