KIO::NetAccess static methods question

[Leo Savernik]

Am Mittwoch, 24. Oktober 2007 schrieb Rafael Fernández López:
> > Well, everyone has been talking about breaking binary compatibility in
> > 4.1 for at least a year now.
> >
> > I did not say it will happen. I said: if it happens, then you can do it
> > in 4.1. Otherwise, it's 5.0 material.
>
> Leo, this is completely true, and I guess this conversations had a
> beginning because everybody knows that our libraries weren't mature enough
> for release, but we had to release at some point.
>
> Personally, breaking between .0 and .1 makes sense because it will let us
> assure a better quality (and cleaner) product the whole 4 lifetime, instead
> of nasty workarounds from .0.

BICing KDE during minor upgrades is the absolutely wrong sign to third party 
developers. It also runs contrary to the promise made since at least KDE 2.0 
that a major version keeps backwards binary compatibility during its whole 
lifetime.

There is an imminent KDE SDK release targeted at third parties to begin 
porting their applications to the new API. Well, what's worth this release if 
we accompany it with the pending message, "Please start porting but don't 
port too hard, we might break BC for 4.1"?

Furthermore, BICing doesn't particularly strengthen the faith in KDE actually 
taking binary compability seriously. If we make an "exception" for 4.1, who 
can assert for certain that 4.2 will really stay BC this time? KDE represents 
enterprise-grade quality and we must neither degrade its quality nor its 
perception thereof by trifling with KDE's reputation by blatantly 
demonstrating lack of professionalism and unreliability on our own promises.

If an incompleteness of KDE 4.0's API is already anticipated, we need the guts 
to either
a) push back the release date (as has happened for every KDE release to date) 
to allow us to fix the API,
b) live with it and fix it later in a BC way, or
c) release 4.0, admit that it didn't cut it, and release 5.0 in place of 4.1 
to make KDE shine.

BICing is no option. Never.

What I find disturbing is the new direction the latent discussion of late API 
changes is taking. Some months ago, there were talks about preliminary APIs 
which were aimed to be introduced as private internal APIs in KDE 4.0 for 
distinct consumers, only to be published later on when they eventually became 
stable. This is a perfectly acceptable step.

Now, we're already discussing intentionally breaking already public API. While 
it's still discussion and no precedent has yet been set, its reification will 
be merely the next logical step. And this step is detrimental because of the 
aforementioned reasons.

mfg
	Leo