The KDE Community is happy to release the third beta for KDE 4.0. This beta, aimed at further polishing of the KDE codebase, also marks the freeze of the KDE Development Platform. We are joined in this release by the KOffice project which releases its 4th alpha release, bringing many improvements in OpenDocument support, a KChart Flake shape and much more to those willing to test. Read on for more.
Since the last beta, most of KDE has been frozen for new features, instead receiving the necessary polish and bugfixing. The components which were exempt from this freeze saw significant improvements as planned, and Aaron Seigo notes, "It is amazing to see the Plasma community growing. The pace of development is amazing, and we're getting really close to having all the features we want for KDE 4.0 available. After that, we have a solid foundation for implementing new and exciting user interface concepts for the Free Desktop".
KDE 4 is the next generation of the popular KDE Desktop Environment which seeks to fulfil the need for a powerful yet easy to use desktop for both personal and enterprise computing. The aim of the KDE project for the 4.0 release is to put the foundations in place for future innovations on the Free Desktop. The many newly introduced technologies incorporated in the KDE libraries will make it easier for developers to add rich functionality to their applications, combining and connecting different components in any way they want.
Comments
I think the kde4 should be released when is complete, not on a specific date(christmas) without major components completed. The KOffice schedule is a more realistic one
current state is alfa, not beta. Maybe some core components are beta, but a Desktop Enviroment should be COMPLETE!!
By whose standards of "complete" should it be released. KDE 3 is still being updated on a constant basis, so by the strictest definition, it is not "complete." By your way of thinking, we would still be waiting for KDE 3.0. I'll take my KDE 4.0 in whatever shape it comes. Sure, I'm putting some faith in the efforts of others, but since they ask nothing in return, I'm not gonna bitch if there are rough edges to be worked out.
Did you actually read the announcement and try it out? I've been using the current version quite extensively, while there surely are some bugs, it is really getting usable. Most applications work really well and look excellent.
I wonder what your findings are based on, it doesn't match my own experience.
apps and components like kopete, kprint, koffice, translations are alfa or very simple ports from kde3. Also nasty bugs(some very old) are still present. My opinion is that kde 4.1 will be what kde 4.0 should have been
You can use KDE3 apps in KDE4 (except kdeprint). And simple ports are fine, since all those apps were great in KDE3, so a port to KDE4 does not diminish their greatness (improvements will come in due time).
KDEPrint from KDE3 should work fine for all KDE3 apps that run on top of KDE4. After all, KDEPrint(3) is part of kdelibs3, and if a KDE3 app is installed then mostly also the kdelibs3 needs to be installed.
In addition, kprinter used as a standalone utility should still work in the same way as it does now. You should be able that you "Export to..." or "Save as..." PDF/PostScript file, and still use kprinter from KDE3 to print it (unless kprinter from KDE3 suffers from serious bugs).
The limitation will be: If you print _directly_ from a KDE4 application, you can't use kprinter[3]. Instead, a new dialog, ${foobar_kprinter4} will appear. We are told this will have less functionality in KDE 4.0, but be back to comparable functionality in KDE 4.1.
About kprinter{3} as a standalone app, see also http://www.kdedevelopers.org/node/3051 .
* You know that some "very old nasty bugs" are still present.
* You know that some components are incomplete (by your definition) or "very simple ports".
Well, okay. All that's as it may be, and of course you're free to be highly unsatisfied if you really want to. Nobody's going to force you to switch to KDE 4.0 - ever, let alone as soon as it's released.
But... What is it that you're contributing (code? artwork? translations? docs?) that will make KDE 4.0 better than you're evidently afraid it will be?
If the answer's "nothing, really", then either put up (contribute) or shut up. Or better, give thanks that so many skilled people are letting you (and me, I admit!) enjoy their hard work.
That's not to say that critical feedback isn't allowed, just that it's rather rude to say "you're only halfway to where I want you to go!" when you're not lifting a finger to help push the boat along.
He's contributing his thoughts, which are very valuable things. Please don't diminish someone's participation just because you don't like the message.
He should've thought a bit more then as to not to waste our time. His opinion is clear, and wrong. "release early and release often". If you don't get Free Software, don't bother wasting our time voicing stupid opinions that don't make sense.
Figure out how FOSS works, THEN you can contribute your thougts. If you're to lazy to do that, just shut up and let us do our job.
Not nice? No, but it's true.
I don't particularly agree with this "release early, release often" idea, at least I don't think it should be followed at all costs.
If KDE 4.0 is a pile o' disappointment (and I sincerely hope that it will be much, much better than the so-called "betas" I've seen so far), it's a HUGE negative PR hit to the KDE project, and then you can try to fix that for a bunch of releases thereafter.
I think it's not surprising at all that people would like to see a KDE 4 we all can be proud of -- the developers, the third party developers, the translators, the docs people, and last but not least the users, who've been waiting for the new and awesome KDE all this time.
Big news:
a) Release early and often is absolutely a must with Free Software. There is no way this could work differently. A lot of people that are part of the KDE community won't join the effort until after release.
b) All the big open source projects that have become successful, did this. One exception was early BSDs, they did not become successful, because they had these guys that didn't publish things before it was really good, which often never happened.
c) We don't need to pretend that KDE development works any different from how it actually works. Quite a few things got redone for KDE4, they are not going to be in all cases ready to surpass KDE3 right now. But they are more ready to do so in the future.
d) The whole point of releasing KDE 4.0.0 is the ability to release an KDE 4.1.0 that has seen a much wider review and participation. This is an absolutely needed and cruical step of the release process. Without public feedback and participation, KDE cannot work. The release of KDE 3.0 was not good in large parts, but it was an absolute necessity to get to where KDE 3.5 is today.
e) Everybody has the absolute right to be very proud of KDE 4.0.0, because it is the best system that we were able to create up to now. The "best" there is often on the design level, on the code cleanups, and the added scope of the framework, and not so much in the polish. So what, that's how it works. If you can't be proud of the KDE 4 evolution and ambition now, you won't be able to contribute to what KDE 4.5 will be like.
f) And that negative PR hit you fear is a strawman. Having people have a realistic view of KDE 4.0.0 is not a problem. The problem is people like you who appear to scare developers about releasing their Free Software, just because it doesn't (already) meet unrealistic expectations.
All you do, is waisting the time of people who are advancing the process. And you contribute to the false perception that KDE should only be allowed to make releases conforming to a standard that it never set itself.
g) I personally am waiting for the stable release to start some work on Koffice2. I need a stable and supported platform on the API level to do that, I do not need it to be all revolutionary and perfect in its GUI. But I may help with that, starting from then.
Yours,
Kay
I'm not taking sides here because I didn't try any of the Betas.
However, release early and often doesn't mean you should tag it alpha, or beta, or RC, or final. It's just about releasing. If you all don't agree with the guy use sensible arguments.
> A lot of people that are part of the KDE community won't join the effort until after release.
So basically you plan to trick them into thinking it's a final release to get them to help you? Do you realise what that will do to the trust and confidence people have in the KDE project?
> All the big open source projects that have become successful, did this.
How many big open source projects that have become successful drop features and compromise quality to meet a release date? It's practically the *opposite* of open-source development. KDE is the exception, not the rule.
"Release early, release often" is not about slapping a final release version number on it. It's basically saying "get your code out there as early as possible, no matter how incomplete, so that people can begin debugging and sending patches". That doesn't mean you should label that buggy code as a final release and it doesn't mean you should trick people into believing that it's finished so that they'll give it a go.
> Having people have a realistic view of KDE 4.0.0 is not a problem.
Look at the negative response on this website, which is full of technically-oriented KDE supporters. There's even people *grateful* that basic features like the panel are working in the third beta! You think the rest of the world is likely to be this forgiving?
> So basically you plan to trick them into thinking it's a final
> release to get them to help you?
That's a rather negative and wrong way to look at things. The fact of the matter is, there are never enough people testing beta versions of software. Beta testers are rare, and in open betas many of them who do test do not necessarily have the inclination to test thoroughly enough or make useful reports anyway. This is a problem faced my many developers in the free/open source world including the Linux kernel developers - often, after a period of testing, you just have to get something out there or you won't have the useful feedback that you need.
The beta releases have bugs. Yes, everyone knows that, and that is the purpose of testing. Those bugs are being fixed, and beta 3 is just that - beta 3 - it is not the release candidate. I sincerely doubt 4.0 will be let out the door with any true showstoppers.
> That doesn't mean you should label that buggy code as a final
> release and it doesn't mean you should trick people into
> believing that it's finished so that they'll give it a go.
Nobody's trying to "trick" anybody. Honestly you and others on this board keep trying to put forward the idea that somehow 4.0 is going to be a bug-filled and unusable release, without having even seen it. The KDE developers are smart people, and they are not going to let that happen.
The level of uninformed and totally unproductive complaining on this forum is getting ridiculous. Please understand, you are not achieving anything other than demotivating the people who are putting the work in. Just have some faith, and some patience, and all will be sorted out.
> That's a rather negative and wrong way to look at things.
And when an end-user installs KDE 4.0 and finds it to be full of frustrating bugs, you don't think they'll look at it in that way?
> Beta testers are rare, and in open betas many of them who do test do not necessarily have the inclination to test thoroughly enough or make useful reports anyway.
Previous KDE major versions managed to produce reasonably stable betas. This is not the insurmountable task you describe it as.
> often, after a period of testing, you just have to get something out there or you won't have the useful feedback that you need.
And that should be decided by what day it is not matter how stable the code is? You really think that?
> The beta releases have bugs. Yes, everyone knows that, and that is the purpose of testing.
There is a world of difference between having some bugs but basically being operational, and having very little work right at all.
I've used every beta since the 1.0 betas. The quality of these is *far* worse than the betas for previous major version. Those betas may have had bugs, but they weren't like this.
> I sincerely doubt 4.0 will be let out the door with any true showstoppers.
How is this going to happen? Because when you start with a much more unstable beta, you need to do a lot more work to fix it up. Are you saying that KDE developers have gotten significantly better at fixing bugs than they were during previous betas? Or are you saying that they weren't trying hard enough during previous betas?
> The level of uninformed and totally unproductive complaining on this forum is getting ridiculous. Please understand, you are not achieving anything other than demotivating the people who are putting the work in. Just have some faith, and some patience, and all will be sorted out.
All I see is the following:
* This is nowhere near working properly. The code wasn't ready for beta. Can't you put off the final release? It's not going to be stable in time.
* Be quiet!
* Troll!
* It's a beta!
* We need the developers to think happy thoughts!
* That's what open-source is all about!
* "i get enough crap from applet and engine writers about shifting targets that i really don't care"
* "to kvetch about that isn't very interesting"
* "i'm not particularly taken by the heartstrings people are plucking here"
If any other open-source project had responses to betas like this, they'd at least take the "kvetching" seriously enough to re-examine their release schedule rather than insulting people.
> And when an end-user installs KDE 4.0 and finds it to be full
> of frustrating bugs, you don't think they'll look at it in that way?
You don't know this is going to happen. Right now you are just spreading FUD on this issue.
> How is this going to happen? Because when you start with a much more
> unstable beta, you need to do a lot more work to fix it up. Are you
> saying that KDE developers have gotten significantly better at fixing
> bugs than they were during previous betas? Or are you saying that they
> weren't trying hard enough during previous betas?
Are you really looking for answers, or are you just trying to be inflammatory? It sounds a lot more like the latter to me. Anyway, in your statement which you repeat from your previous posts, you have not accounted for the fact that there are more people working on KDE now than ever before. Which satisfies your requirement for "more work".
>... It's not going to be stable in time.
You keep implying this, but you have no way of knowing for sure that it is true.
> Are you really looking for answers, or are you just trying to be inflammatory?
I'm really looking for answers, and nobody is answering, just dodging the questions. Don't call me a troll. That's really insulting. Why do you think it's impossible to be anything other than a brown-nose or a troll?
> Anyway, in your statement which you repeat from your previous posts, you have not accounted for the fact that...
Hey, somebody is finally attempting to answer me. Did it ever occur to you that I'm repeating it from previous posts not because I'm a troll but because nobody has attempted to answer this question until now?
> you have not accounted for the fact that there are more people working on KDE now than ever before.
You're right, I haven't accounted for that. How many more people are working on KDE? In what capacity? Are they application developers or library developers? Are you aware that adding developers to a project can actually be counter-productive? Have you read, e.g. The Mythical Man-Month, Peopleware or Death March?
> >... It's not going to be stable in time.
> You keep implying this, but you have no way of knowing for sure that it is true.
And you have no way of knowing for sure that it is false. But you seem awfully keen on telling me to shut up and "have faith" in the developers, which seems like an odd thing to do when they show every indication of caring more about a release date than stability.
What do you think of this?
> If any other open-source project had responses to betas like this, they'd at least take the "kvetching" seriously enough to re-examine their release schedule rather than insulting people.
Do you agree? Do you think re-examining the release schedule is unreasonable? From the way you talk, it sounds like you think everybody should just shut up and just *hope* that 4.0 works okay. That's not like any open-source project I'm familiar with.
> I'm really looking for answers, and nobody is answering, just dodging the
> questions. Don't call me a troll. That's really insulting. Why do you think
> it's impossible to be anything other than a brown-nose or a troll?
No, I don't think it's impossible, and I did not call you a troll, I said you were being inflammatory. Which you were. Not necessarily because of what you said but the way you said it.
> How many more people are working on KDE? In what capacity? Are they
> application developers or library developers?
No idea. If you are interested I am sure you could make a study of it.
> Are you aware that adding developers to a project can actually be
> counter-productive?
Yes I am, and you are right, there is a point where too many people can be detrimental. I'm not convinced that KDE has quite reached the size where that has occurred, but it is definitely something to keep in mind when a project gets larger.
> Do you agree? Do you think re-examining the release schedule is unreasonable?
It's not my decision to make. If it is the right decision closer to release when we know more about the state of 4.0 final, the KDE release team will make it. Regardless, complaining on this forum is not really the right way to go about effecting change in KDE release policy.
> That's not like any open-source project I'm familiar with.
I am sure that the reception of many open source projects to comments such as the ones on this forum lately from relative outsiders would be somewhat less than enthusiastic.
> > Why do you think it's impossible to be anything other than a brown-nose or a troll?
> No, I don't think it's impossible, and I did not call you a troll, I said you were being inflammatory.
You said:
> Are you really looking for answers, or are you just trying to be inflammatory?
If I weren't really looking for answers and just trying to be inflammatory, I would be trolling. You *were* calling me a troll, whether you meant to or not.
There are some people here, and I feel you are included, who react to any criticism that doesn't include glowing praise to offset it as if it were a troll. That certainly gives the impression that you are dividing the world up into two categories, praisers and trolls, with no room for people who have real questions but no desire to praise.
> Not necessarily because of what you said but the way you said it.
Criticism without ego-stroking is not unreasonable.
> > How many more people are working on KDE? In what capacity? Are they application developers or library developers?
> No idea. If you are interested I am sure you could make a study of it.
You can't say that KDE is going to fix the bugs quicker because there are more developers, and when I ask how many more, admit that you haven't got a clue. How do you know that they are going to fix the bugs quicker then?
> I am sure that the reception of many open source projects to comments such as the ones on this forum lately from relative outsiders would be somewhat less than enthusiastic.
How many open source projects would let it get to this stage though? Take a look at what's happened: the first beta was released that was utterly broken for many people. The people pointing out that a beta should be at least barely operational were ridiculed and called trolls. The second beta was released, same thing. The third beta was released, same thing.
The response to this third beta did not come out of nowhere. It is a direct result of previous actions by the KDE project that no other open-source project would take.
> "release early and release often"
"Release early and release often" does *not* mean that you should rush to label any old crap as a final release.
Want to make lots of releases? Go ahead! Have lots of alphas and betas. But don't drop features, ignore bugs and call the resulting mess 4.0 because you want to hit a deadline.
That's not what "release early and release often" is all about, and if you think it is, then it is *you* that doesn't get Free Software. Free Software does not revolve around intentionally keeping everything in a permanent beta state.
Hello,
even Free Software needs a project planning and regular flow of releases. In these cases whatever is not ready is being pushed to the next release and only a few things are allowed to be absolute showstoppers.
These guys work for fun. Making them stuck in Beta with no users getting to see what was done so far, means no feedback, means no incentive to complete something on time. And why would developers of Phonon have to wait for the other guys that had enough time? Why would waiting any longer suddenly make lots of developers switch their occupation to doing what wasn't done so far?
In practice that would mean, nobody would write any kind of documentation, and nobody would do translation already. Application developers wouldn't yet start to think about porting their own programs. And you would loose these guys who are going to provide fixes, but not during development, because it's not what they currently use.
Ain't it funny how your last sentence is the only one that made sense? Keeping everything in a permanent and artificial beta state would indeed hold everything back.
And final release? It's going to be an initial release. Since when did a major architectural restructuring a software to be immediately surpassing the previous result of many years of maintance? How is waiting without release even going to allow this to EVER happen?
Yours,
Kay
> even Free Software needs a project planning and regular flow of releases.
I am not arguing against project planning in general. I am arguing against *this particular* project plan.
> In these cases whatever is not ready is being pushed to the next release
But it isn't a case of things that aren't ready being pushed back. You *can't* push back kdelibs, khtml, etc. If they aren't ready, then they make the whole of KDE unstable and you can't just leave them out. And when it's a component you *can* leave out, it reduces functionality compared with what was there before.
> These guys work for fun.
Some do, some don't. I believe the core contributors and people who set the release schedule are paid to work on KDE.
> Making them stuck in Beta with no users getting to see what was done so far, means no feedback
Doesn't this thread disprove that claim? There's already been a lot of users seeing the betas and there's already been a lot of feedback. You don't need a buggy final release for feedback.
> And why would developers of Phonon have to wait for the other guys that had enough time?
They don't. Development doesn't have to happen in lockstep. Just create a new branch for 4.1 development and the modules that have been finished can push ahead without waiting for the modules that aren't stable.
> Why would waiting any longer suddenly make lots of developers switch their occupation to doing what wasn't done so far?
I don't understand what you mean by this.
> In practice that would mean, nobody would write any kind of documentation, and nobody would do translation already. Application developers wouldn't yet start to think about porting their own programs.
Why do you think this?
I think you have misunderstood me somewhat. I'm arguing that KDE isn't beta quality yet, and that the release schedule shouldn't prematurely slap a 4.0 version on it. That doesn't change the code or speed of development in any way. Calling something 4.0 a month later doesn't slow down development by a month, it just means that what is called "4.0" has had a month longer to mature.
> And final release? It's going to be an initial release. Since when did a major architectural restructuring a software to be immediately surpassing the previous result of many years of maintance? How is waiting without release even going to allow this to EVER happen?
Can you try rephrasing that? I don't understand you.
"Making them stuck in Beta with no users getting to see what was done so far, means no feedback"
This is not true. Betas can be (and are) provided to users. Just look at Mplayer. The reason to tag something stable shouldn't have anything to do with wanting more people to install it, that is just decieving the user.
And again, I am NOT taking sides here. I didn't try the Betas so they may well be quite good as far as I know.
113 BUG REPORTS. thats my main contribution ;)
Thank you. While it sometimes takes us developers (I say that if I have done any kde work in the last few years...) are while to get to bug reports, we do appreciate the effort. Good bug reports make our job much easier. Contrary to popular belief, they also make it more fun.
That, my friend, is a load of bollocks.
"when you're not lifting a finger to help push the boat along.
Great. This is the correct attitude. Because the world has two types of people: artists that could contribute to KDE, or programmers that could contribute to KDE.
There is no such a thing as people that hasn't got the skills to do any of them. No?
I'm tired of this childish attitude already.
If there is no criticism, you sleep on a bed of complacency, ffs, and never go forward.
Grow up.
> There is no such a thing as people that hasn't got the skills to do any of them. No?
Artwork or coding? Perhaps there are, but this is a false dichotomy.
There is plenty of work to be done in a large project like KDE. Some useful activities are, for example:
Coding
Artwork
Translation
Alpha and Beta testing
Filing good bug reports
Building precompiled packages
Running and administering project webpages
Helping spread KDE/other Free Software projects through LUGs and word of mouth
Most people can do some of this.
"Most people can do some of this."
Maybe you should also accept that there are people out there who like to use KDE and share their positive _and_ negative impressions for the common goal of a superior desktop, but who can't do any of this.
Maybe you heard that all this takes time and maybe people have other priorities - work, job, family, real life - despite favoring KDE and taking an active part in discussions on the desktop (so called "users")?
Seriously, we all can debate on release schedules and so on, but the worst possible arguments concerning a desktop environment aimed at the and user is "you don't code, so you are not entitled to have an opinion."
> Seriously, we all can debate on release schedules and so on, but the worst
> possible arguments concerning a desktop environment aimed at the and user is
> "you don't code, so you are not entitled to have an opinion."
Yet this is not what anyone is saying. I was merely pointing out that there are things other than coding that one can do. And you still managed to completely miss it, as witnessed by your last sentence.
An open source project is not a free giveaway anybody is entitled to. It is a vibrant community, first and foremost, and every member of this community is a volunteer. There are many members of the community: programmers, translators, artists, documentation writers, webmasters, beta testers, bug reporters, people providing extra material (educational files, etc), modders, and, yes, even regular users who take part in the community by discussing their experience in a respectful way and offer constructive suggestions. But they all form a community which produces a software platform in a cooperative and organic manner. And the barrier to entry (writing documentation, or proofreading documentation or beta-testing, for example) is ridiculously low.
I haven't seen anyone here saying users shouldn't provide constructive criticism. But there is a difference between constructive criticism and "Look, I don't wanna do shit, I just want you to write me a software for me and it should be like this this and this, cuz right now it's shit."
In short, nobody owes you anything.
> Maybe you should also accept that there are people out there who like to use KDE
> and share their positive _and_ negative impressions for the common goal of a superior
> desktop, but who can't do any of this.
I fail to see how one can have the time to bitch for hours on a weblog in the pursuit of the common goal of a superior desktop, but cannot submit a bug report.
Anyone who can share their positive and negative impressions can also submit a bug report or beta-test or proofread documentation.
Of course, everybody's (respectful) input is welcome, but the length at which people go to avoid contributing and justify trolling internet forums is quite amazing.
Funnily, the way you try to refute my point only proves it the more ;). But you probably didn't even notice it.
Anyway, as you are so involved in the KDE development, you might have noticed from your regular visits to the KDE developpers blogs that there are some contributors who voice the same concerns as they are voiced by the stupid, thankless, lazy non-coding users here, so maybe...
Concerning myself, I simply stopped trying out the KDE betas, its good enough to have some of the new apps running with good old KDE3. As many people already observed, quite some apps are already usable and simply better than their KDE3 equivalents (konsole).
> Funnily, the way you try to refute my point
> only proves it the more ;). But you probably
> didn't even notice it.
No, I didn't. Care to explain?
Perhaps our thoughts aren't all that different. I'm just saying two things:
- Comments and suggestions are welcome, but this is a volunteer project and nobody owes the "user" anything. Nobody is saying that only coders are allowed to comment, just that the coders are not paid to suffer insults from abusive people on the internet.
- It is not THAT difficult to contribute to KDE as some people make it out to be.
The two are unrelated.
> apps and components like kopete, kprint, koffice
Yes and guess what, KOffice is released as Alpha ! And won't be release as final before at least six more months. As for kopete, its developers are still not sure wether it will make it for 4.0. Other application, like KDevelop or Quanta have decided to skip 4.0. But that shouldn't be much of a problem, as work has been made to ensure KDE3 applications to run fine in a KDE4 environement.
If you think so, step up and help. There's a lot you can do even outside coding, such as translations, documentation...
Folks, can't you just stop this mindless bashing? Do you realize it only has negative effects on the developers?
Repeat after me: "Release early, release often".
That's the Free Software way. If we would be microsoft, KDE 4.1 would be our first release. But we're not. We need to get this out there, so users can report bugs and request features and developers can start tinkering with it.
Simple as that.
No, if we were Microsoft, we'd release KDE 4 beta 2 about five years from now. ;)
You are full of it if you think for a second that the amount of work done on Vista RTM isn't better and more stable than KDE4 beta 2.
Vista actually is worse, they demanded from their BUYING users that they Beta-Test their application framework.
How can you compare this to KDE, which is "just" a desktop environment?
Vista is a piece of crap, which is why companies are not moving to it, it is why computer manufacturers are still selling XP, because the demand to move to Vista was weak. And it is why linux has picked up a lot of business customers.
KDE is at beta 3, with a hell of a lot of work being put in by developers, and Novell working damn hard on it as well, so all the Ubuntu Novell Haters will get their nice new shiny KDE. I tend to think people judging KDE4 on the beta's should shut up, and realise it is a beta, and wait for the final release.
> I tend to think people judging KDE4 on the beta's should shut up, and realise it is a beta, and wait for the final release.
I've used KDE since the 1.0 betas. None of the betas of previous versions have been anywhere near this bad.
The problem is not that this is beta quality, the problem is that this *isn't* beta quality.
Release early, release often isn't about alpha quality software.
Gnome is releasing early, releasing often. Six months schedule, but every feature included has to be stable or else it gets cut and will be included in the next release. Or for the X+2 release. Or X+3. But it has to be stable.
Really? Then that's probably one of the main reasons Gnome is so far behind KDE.
One thing I love about KDE is that it is a great group of really bright people who are not afraid of experimenting with new ideas. If something breaks for a while as a result, that's OK, because the end result is worth it.
Erm. Did you ever use KDE 3.0? KDE 3.0 *exactly* looked like KDE 2 although under the hood quite some things had changed (not only Qt 2 -> 3).
Many people complained that time KDE 3.0 isn't complete and ready and that KDE 2.2.2 is much more better... But KDE 3.0 was absolutely necessary for the great success of KDE 3.x
I could go back in time further. KDE 2.0 was a big change from KDE 1. A *huge* number of KDE 1 apps was not ported when KDE 2.0 came out. KDE 2.0 had some very rough edges and KDE 1 was still in use for quite some time.
So look at the old big KDE transitions how they went out. There is nothing unusal with KDE 4.0 release scedule compared to them.
None forces you to use KDE 4 inmediatly. KDE 3.5.8 is a great release.
Yes, kde 3.5.8 is great, but still konqueror can't use latest netscape-flash or swfdec because XEmbed is missing. So people will start to use firefox and move all their bookmarks there. Guess what? They'll not come back easily,
if firefox doesn't broke itself.
Can't speak for swfdec, but the latest version of Macromedia Flashplayer works great in Konqueror here (much better than the older versions used to work).
> There is nothing unusal with KDE 4.0 release scedule compared to them.
What he said :).
I (like everybody else) don't know what the final product will be, but my personal opinion is that at least very basic things who are currently missing should be in place when they release. Do File -> Open in KDE 3.5.x and 4.0 SVN (beta 3). The file dialog box in KDE 3 can do just about everything (even preview video files, open files on remote SSH locations using fish://, etc).
I tried File -> Open in KDE4's kate and that was enough to determine that KDE4 isn't even close to complete, nor does it fit the description "beta3" (alfa3 perhaps). Simple affect-every-application things like file dialog boxes really need to be complete or these things will make ALL the KDE4 software unattractive.
I'm really looking forward to the new beta release!
But I think, concerning the naming of "beta releases", there should be one big "lessons learnt" from the KDE4.0 release cycle:
Nowadays, if a program is tagged "beta", it is expected that basic functionality is in place und an end user can install and use the software, albeit with some missing functionality and errors (for which he can file bug reports). Everything lesser should simply be labelled "alpha", in order not to raise unfulfilled expectations.
If I read the comments here, KDE4 seems nearing this kind of beta-status with the beta3 release, and that's good. For all prior versions, I didn't even think of filing bug reports - because so much was broken, I wouldn't know where to start. (Yes, I know, KDE has defined "beta" by certain internal milestones, API freezes and so on, but this criteria is of no value to the average non-developper end-user, at whom betas are targetted!)
But apart from that - thanks for all the work!
> the average non-developper end-user, at whom betas are targetted
A beta is not targetted at the end-user. KDE uses the classical definition of Beta, and that means "functions - OK, stability - TODO". What you mean with beta is the Google definition: "The software is finished, but there might be one bug remaining."
Functions - OK?
Beta 1 and 2 weren't anywhere close to that, and I still can't open a damn thing with Konqueror in beta 3. That doesn't sound like "functions: okay" to me, sorry.
"functions: bleeding, stability: bleeding" is alpha quality, no matter how you look at it.
Thankfully from what I've seen Beta 3 has been incomparably better than the previous "betas", so yeah.