KDevelop 4.0 Release

[David Nolden]

Am Montag, 8. September 2008 23:14:20 schrieb Andreas Pakulat:
> On 08.09.08 10:35:02, David Nolden wrote:
> > I think stuff like the duchain viewer should stay in KDevplatform, nobody
> > would even get the idea to try such a small thing out when it was lying
> > in playground.
>
> Then I'd like to ask you what the purpose of the duchain viewer in a C++
> IDE is?

It's only a debugging utilities for developers working on KDevelop, so it 
should _never_ appear in any release. Still, nobody is going to use it when 
it's in playground.

> > Then we
> > can leave plugins that we want to have, but that aren't ready _yet_ and
> > developer plugins like the duchain viewer, directly in the source tree.
>
> I disagree, plugins that want to be in the core kdevplatform module or
> the kdevelop module should be ready for public use. Anything else either
> needs to go to extragear or playground. We'd like to avoid the mess that
> we had in kdevelop3 and we already started with that again - for example
> the snippet support still has multiple bugs and gets no attention, or
> cvs support which is also unmaintained since about a year I think.

I'm not talking about stuff that is unmaintained and that we don't think is 
essential, I'm talking about stuff like the debugger, plugins that we core 
developers think is absolutely needed, but that we cannot get ready for our 
first release.

Moving stuff to playground greatly reduces the probability that it's going to 
be picked up, it's like a jungle of unmaintained code. When we keep something 
in KDevelop, we can easily point new developers asking what they can do at 
it, or we can ourselves work on it when we feel like it, without a barrier.

I agree in what you're saying about avoiding the mess, I too don't want 
KDevelop to be a gigantic set of half-baked plugins. I'm just talking about 
stuff we think is important, that has a chance to be finished by someone, but 
that isn't release-ready, considering that we want to do an early release.

Another option would be having something like kdevelop_unstable_extras in 
playground, a central place where all the promising but unfinished plugins 
can live until they're mature enough to be moved into the main tree.

Greetings, David