The reason KDE 4.0 was numbered such wasn't an indication for users to start using it - it was for developers to start developing for it. The core libraries and APIs were considered, "stable": something developed against 4.0 would continue to work against later versions of KDE. The fact that Kubuntu's Amarok, compiled against 4.4, then works against 4.5 helps to demonstrate the meaning: developers could be confident about developing against 4.0 (as indeed, the Amarok developers did when using Plasma for their context view) and having their application work against future versions of KDE without having to re-write bits of it.

Madman wrote:The reason KDE 4.0 was numbered such wasn't an indication for users to start using it - it was for developers to start developing for it. The core libraries and APIs were considered, "stable": something developed against 4.0 would continue to work against later versions of KDE.

This is very interesting - re. my earlier post, this is precisely the kind of thing which all of us (developers, packagers, distros, users ...) need to understand clearly.

About version numbering:
do people remember that tex have a version number that tends asymptotically to pi (now it is 3.1415926 according to wikipedia)?
do people remember that the Linux kernel do not have alphas or betas, but only lots of release candidates?
do people remember that before 2.6 series, Linux kernel was considered stable when version number was even and unstable when odd? (Wine follows this convention now...)
...
The list of "irregular numbering conventions" is large enough to consider there is no convention possible. KDE 4.0 was what developers said it was: a technological preview. That was clear since the beginning. It was also clear since the beginning that 4.2 was the first "(at least for many) user ready" version.
I never understood where the problem was.
Oh well...

The version numbering system was a little unfortunate, but the real communication problem was somewhere else.

The problem was that at the time there was an awful lot of hype about how great KDE4 would be - many people misunderstood that to mean "KDE 4.0" instead of the potential of the whole 4.x series.
Adding to that, the most influential press outlets that reported on the release of 4.0 seemed to not have read much more than the release announcement - and that announcement was less than clear on the whole "development release" issue. Anybody who had been reading blogs or the dot regularly knew very well what to expect, but the reporters didn't.

It's a little tragic: I don't think KDE ever before managed to build such a hype - but it might have hurt us more than it helped us.

Referring to how Developer's and Users can have a better way of discussion, I feel that the channels we have now are too unorganized and hard to consider. KDE Brainstorm is a great tool, but I believe KDE needs a way to take those ideas and categorize them and compare. For example, when you want to post an idea for Dolphin, you make a new post with your idea and then others vote on it. What would be nice is if you could take these ideas and put them into categories, eg: Dolphin, Plasma Mobile, Kopete, Amarok, etc.. Then when you click on the category and it would show a list with 20-50 ideas, one line per idea, organized by rating, # of votes, or date. There could even be sub-categories if there were several ideas for doing the same thing.

I feel like the bugs/wishes and brainstorm ideas would be much easier for users to sort through if they were organized by category/application, and then gave us an easy way to view all ideas side-by-side in one place. This could help user/developer communication by giving one, organized, place to go when a user thinks of a new way of doing something or a developer wants suggestions for how to do something.

I was just writing this as a reply but I think Ill make a brainstorm post of it.
brainstorm.php#idea89090_page1

fraxinus wrote:

jglen490 wrote:I'm not sure all that will happen, but some things need to improve so that never again is there a KDE 4.0 even if the first release cycle is somewhere between 4.0 and 4.4. Hey, just sayin'

Interesting points in many of these posts. I view the 'KDE 4.0' issue slightly differently from jglen490.

IMHO the real problem with KDE 4.0 was NOT that it was incomplete - it was that mainstream distros decided to ship it in that state, so that their KDE users had no choice but to accept it if they wanted or needed to use these distro's current releases. Perhaps KDE and distros need to have as clear as possible a shared understanding of when new software is sufficiently mature to enter the mainstream - i.e. clearer shared definitions of what is 'stable' and what is 'testing'. This is especially important for a project like KDE at the present time, since it has seen such high levels of radical change and innovation over the last two years.

I'm sure the distros incorporated and shipped what they had available to them. If there was an understanding within the KDE development community that 4.0 was not ready for prime-time, abd perhaps 4.1 only a little more so, then perhaps it should NOT have been made available for distribution. After all, the capabilities of the product as incorporated into a distro (i.e., Kubuntu, Mandriva, etc.) are a direct reflection of the state of the component (i.e., KDE). A desktop environment, or whatever you choose to call it, is a GUI user's most important tool. For those who want to use Linux primarily through a graphical environment, that environment is paramount to their opinion of the entire package.

I've been using KDE-based distributions for many years now. I have in the past used Gnome, XFCE, fluxbox, and a variety of other window managers of various levels of sophistication and integratibility. I like the graphic experience even though I also make good use of the command line. I've always come back to KDE because it was the best way to interact in a visual manner with the underlying hardware and OS. Maybe not the most efficient, but certainly the most satisfying.

I have been accused of being negative, disruptive, whiney, a generally a pain in the ***, perhaps I am perceived as the anti-fanboy in the wrong environment. But it's just like fingernails on a chalkboard when a product that I really enjoy, admire, and like comes out of the gate flat on its face. If it feels like I'm kicking people in the *** or poking you in the eyes, it's because you need to know the reality of the way the product acts. Does it have to be perfect? Of course not, but when it acts incorrectly it's not always PEBCAK, even if it works right on YOUR machine.

O.K., I'm braced for more negative Karma

jglen490 wrote:I'm sure the distros incorporated and shipped what they had available to them.

Some did, some didn't. Some followed the KDE team's advice, others didn't. Those that didn't also tended to be the ones that have a history of pushing unfinished and/or unstable software.

jglen490 wrote:If there was an understanding within the KDE development community that 4.0 was not ready for prime-time, abd perhaps 4.1 only a little more so, then perhaps it should NOT have been made available for distribution.

KDE is an open-source project, it is impossible to prevent distributions from using it if they want to. If some distributions refuse to listen to the advice of the software providers, there isn't really much an open-source project can do about it.

jglen490 wrote:After all, the capabilities of the product as incorporated into a distro (i.e., Kubuntu, Mandriva, etc.) are a direct reflection of the state of the component (i.e., KDE). A desktop environment, or whatever you choose to call it, is a GUI user's most important tool. For those who want to use Linux primarily through a graphical environment, that environment is paramount to their opinion of the entire package.

It isn't that simple. It is a direct reflection of how the state of the component meshes with the philosophy of the distribution. Some have a philosophy of pushing the newest stuff even if it isn't ready. Some have a philosophy until waiting until it is ready for prime-time. Some have a philosophy until waiting until it is very stable. Still others have a philosophy of waiting until it is way past its prime. Upstream projects cannot control which software and which versions of software distributions choose to package. If the software has reached a state where it meshes with the philosophy of a given distribution, that distribution will use it. But software project have no control over where that point is for any given distribution, and they have no way of preventing a distribution from using software whenever it wants to.

You are right; KDE is open source. It also does have a development cycle which includes a release component. If it's not ready, don't release it out of your development domain.

Now I understand that the entire pipeline is at the mercy of events over which there is very little control. The move from QT3 to QT4 and the desire to not try and maintain software on an unsupported QT3 platform, but if it isn't ready you don't have to let it out into the wild.

Linux is always about choices.

jglen490 wrote:You are right; KDE is open source. It also does have a development cycle which includes a release component. If it's not ready, don't release it out of your development domain.

What makes you think it would have made any difference? Do you really think just changing the number would have prevented distributions from using it? That is really the only thing that would have changed, the number assigned to that branch of the svn tree. That doesn't speak very highly of distributions, if they just look at version numbers and can't be bothered to pay attention the release notes.

TheBlackCat wrote:

jglen490 wrote:You are right; KDE is open source. It also does have a development cycle which includes a release component. If it's not ready, don't release it out of your development domain.

What makes you think it would have made any difference? Do you really think just changing the number would have prevented distributions from using it? That is really the only thing that would have changed, the number assigned to that branch of the svn tree. That doesn't speak very highly of distributions, if they just look at version numbers and can't be bothered to pay attention the release notes.

I remember very clearly what was going on when KDE4 was released. There was alot of excitement about the new KDE4 technologies and once KDE 4.0 was released most distributions included it in some form or another. This was *IMO* mostly because of all the user attention and demand to try it out. Distro's give its users what they want, and if they complain that it wasnt ready for full time use then they should have stuck with KDE 3.5. Most Distros offered both options for quite a long time. Anyways, it was a necessary period of adjustment, and its almost over. There's no need to keep blaming the distros for what happened.

Do you really think just changing the number would have prevented distributions from using it?

I cannot remeber seeing a note in the announcements of KDE4 that says "Hey, this is alpha, if you push it on your users you'll have trouble"

Funny thing, poll choices 1 and 3 are not excluding.

Some distributions, such as Fedora, do push alpha software on their users (look at the graphics drivers). So it wouldn't have made a difference.

Well, I do not think this is true for Debian or other conservative distributions. Anyway, no need to talk about the "would haves", it has already happened, there's no control group in this experiment.

Here is a good example: K3B. The stable release came out just recently, but many distributions have been shipping the unstable version as the default version despite it being clearly marked unstable, or even alpha in some cases.