[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: i18n freeze ?
From:       Stephan Kulow <coolo () kde ! org>
Date:       2000-10-19 11:09:49
[Download RAW message or body]

Dirk Mueller wrote:
> 
> On Don, 19 Okt 2000, David Faure wrote:
> 
> > Yes, please stick to binary AND source compatibility for kdelibs (*)
> > (as well as what I call "behaviour" compatibility). A KDE 2.0 application
> > must run fine on top of kdelibs 2.1.
> 
> I didn't ask the other khtml/kjs/kjava developers yet, but how is khtml
> affected by that?
> Given a impressive userbase of khtml and given that we receive an incredibly
> high amount of duplicate bugreports for khtml (maybe doublicates on the same
> URL, but often different urls which show the same bug on different
> webpages. users have difficulties to realize that) I'd rather like to be
> able to release updated versions of it every 3-4 weeks, at least until we
> reach a certain kind of stability.
> 
> any comments on how to make this fit into our release plans?
> 
> We have no infra structure for releasing kdelibs separate from the other
> modules, so this can cause quite a few problems.. (i.e. the "KDE version" is
> defined by #defines in kapp.h header file)
> 
If you think, that will change the bugreport situation I have to call
you dreamer. If Suse 7.x ships with KDE 2.0 as default desktop, user
won't care if there is a KDE 2.0.8 on ftp.kde.org. Especially if it's
kdelibs only. I would rather suggest disgarding all bug reports against
old installations. For example in 4 weeks we would stop all bug reports
against KDE 2.0. As David said: we have limited resources and our 
most limited resource is developer time. We better keep it in one
branch and make KDE 2.1 even more stable.

Greetings, Stephan

-- 
... but you ain't had mine

[prev in list] [next in list] [prev in thread] [next in thread]