Frank Steiner wrote:
There was quite a long delay when moving to opensuse, which is understandable. The interesting question is, if it will be possible again to run a SLES and the SuSE version with the same codebase until the next SLES is released. With SLES9, this was not possible, because 9.1 was dismissed before SLES 10 was released. Since we try to run SLES on the important servers and the matching SuSE version on all other hosts, this was a problem. We need some time (2-3 months) to plan and perform the upgrade on all servers, so I really hope that 10.1 will be continued until SLES 11 has been out for some months.
For that to work, the SLES release cycle should not be longer than about 1 1/2 years. Can you say sth. about the planned release cycle for SLES?
Naturally using SLES/SLED for your important boxes, and openSUSE for your other machines, is the intended design. We put a lot of work into the common code base, so that packages for SLES work on openSUSE and vice versa. So when a given SLES release, and corresponding openSUSE .1 release, come out, you deploy them simultaneously. You hit a problem 2 years later when support for the .1 release expires, but the next generation SLES has not been released yet. You could solve this problem by deploying more SLES instead of openSUSE. But that costs money. So instead, you could solve this problem by upgrading the .1 machines to 2 or .3, which certainly have not expired before the next SLES comes out. But that costs effort. Saving you from forced upgrade effort is the value proposition that makes SLES cost money, so generically if upgrading too often is the problem, then buying SLES subscriptions is our proposed solution. Your schedule of using only .1 releases and rolling them just as the new SLES release comes out is elegant. I don't think that the company *deliberately* scheduled the expiring of .1 support and release of new SLES editions just to prevent your schedule from working; I don't think we're that clever :) But now that you've pointed it out, I will ensure that it is at least a conscious decision. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering, Novell http://novell.com Hack: adroit engineering solution to an unanticipated problem Hacker: one who is adroit at pounding round pegs into square holes