faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: A HUGE job indeed.
by James Richard Tyrer on Thursday 11/Aug/2005, @13:12
|
Yes indeed, it is a HUGE job.
I can't help but wonder if this is the wisest course of action. That is, a professional software developer would advise against the plan. We are doing several things at once and this is not wise. If things work out correctly, we will probably have a great product, but if they don't, we could wind up with a large mess on our hands.
A more conservative road map would be to just do the port and release it as 4.0 and THEN start on radical changes for 4.1.
IAC, with the current plan, I expect to see delays so we should plan on a 3.6 release. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
|
Over 40 comments listed.
Printing out index only. |
Re: A HUGE job indeed.
by Segedunum on Thursday 11/Aug/2005, @13:28
|
Not really. It's called unstable development, and it happens in every single project, commercial or otherwise. You get to something stable through iterative development and improvements.
|
[
Reply To This | View ]
|
|
|
Re: A HUGE job indeed.
by odysseus on Thursday 11/Aug/2005, @13:54
|
The aim of the large versions numbers (v3, v4) is to maintain binary and API compatibility through-out so that app developers can be guaranteed their exsting code once ported will continue working throughout the series (i.e. code written to v3.0 still runs unchanged on v3.4). To have a v4 and v4.1 with radically different API's is counter to this aim. What you propose is what in effect is happening, but just without the public release in-between. First a port to QT4, then change the API as required, then release v4.0.
John.
|
[
Reply To This | View ]
|
Re: A HUGE job indeed.
by Christian Loose on Friday 12/Aug/2005, @00:17
|
> That is, a professional software developer would advise against the plan
And we are all just hobby software developers, right? I can assure you that there are more professional software developers working on KDE than you might think.
> A more conservative road map would be to just do the port and release it as 4.0 and THEN start on radical changes for 4.1.
a) And what should our user do with this great KDE 4.0? Doesn't make sense to release stuff that is just a port to a new library version.
b) We aren't doing several things at once. The plan is to first port KDE to Qt4 and then make the big API changes. Nothing else is happening in SVN. We just don't release the port to the public (see a).
> IAC, with the current plan, I expect to see delays so we should plan on a 3.6 release.
We don't have the man power for another KDE3 release. After KDE 3.5, everybody will be working on KDE4.
|
[
Reply To This | View ]
|
|
|
Re: A HUGE job indeed.
by Nadeem Hasan on Friday 12/Aug/2005, @04:13
|
This is not really workable. If we release 4.0, then the BC compatibility requirement comes in force which will then stop us from doing any "radical" changes. The model currently followed has been used before and has worked very well for us. Think about KDE2 -> KDE3 effort. KDE3 has been hugely successful so far.
|
[
Reply To This | View ]
|
|
|
Re: A HUGE job indeed.
by Chris Howells on Friday 12/Aug/2005, @06:12
|
A complete insult to the large numbers of highly skilled professional software devlopers that _are_ working on KDE and have done since it inception.
But I should have known, James Richard Tyrer is the expert softare developer that can save KDE from impending doom.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
