plans for long term support releases?

Ola Thoresen redhat at olen.net
Wed Jan 17 22:10:14 UTC 2007


Horst H. von Brand wrote:

> One of the reasons /not/ to ugrade and wanting to stick with the same
> distribution release is precisely because new upstream releases break
> stuff...
> 

<snip>

> Yes, GCC 4  ...

> Yes, Python 2.6 ...

> Yes, PHP 5 ...

And they allways will.  And at one point you MUST upgrade.  If it is 
after 1 or 5 years does not really matter.  You might have more time 
between upgrades, but on the other hand, you will have more 
incompabilities between the releases.

What I want us to focus on, is to make upgrades as easy and smooth as 
possible, and make sure we _document_ the important changes, and help 
users and admins in the best way possible to make sure they can trust 
the upgrade to not cause days and days of work just to get back to where 
they were before the upgrade.

- These are the things you need to test when upgrading from GCC 3 yo 4.
- Here are a couple of scripts that checks your inhouse code for the
   most common problems with old python-scripts on the new version.
- Here is a quick list of important incompabilities between PHP4 and 5,
   so you can grep all your php-files for these function-names.

That way we know what to look for, and we can warn the users about the 
forthcoming change.

One of the worst examples of this is the change to UTF-8 as default 
charset.  I am a devoted UTF-8 user myself, but it is probably the 
single change that has caused most pain for others, and it is stil 
causing trouble.  When we changed to UTF-8 as default, there were no 
easy way to convert filesystems, documents, text-files, webpages...
The first thing almost everyone I know that are installing Fedora, 
Redhat or Suse is doing is to change /etc/sysconfig/i18n to go back to 
en_US as default LANG. Simply because it takes a h... of a lot of work 
to convert all your files and applications and there are no good tools 
out there to help you.

We should also try to make config-converters so old configurations can 
be translated semi automatic.

If I get a new GCC on one upgrade, a new PHP and perl on the next and a 
new python on the third, I can at least concentrate on one or two major 
   changes.  With good documentation I can run a few tests, check the 
output of some commands, and trust that most things will work.

But i really do not look forward to the upgrades from RHEL4 to RHEL5, 
where we get 5 years of upgrades in one go.



-- 
          _,--',   _._.--._____
   .--.--';_'-.', ";_      _.,-'   Ola Thoresen
  .'--'.  _.'    {`'-;_ .-.>.'
        '-:_      )  / `' '=.      It is easier to fix Unix
          ) >     {_/,     /~)     than to live with Windows
          |/               `^ .'




More information about the fedora-devel-list mailing list