Future KDevelop 3.4.x releases

[Andreas Pakulat]

On 24.05.07 16:08:05, Matt Rogers wrote:
> All the indications from the release-team indicate that the KDE 3.5.x branch 
> will continue to remain frozen for new features and new i18n strings. So, 
> because of that, I'd like to ask that we focus our efforts now on KDevelop 4 
> and let KDevelop 3.4.x rest in peace.

Agreed from my point, although that leaves two user requests unsolved:

a) the extensive height of our C++ support page, which can only be
reduced more by some re-arrangements and thus string changes
b) an option to disable the search for new files during opening a
project with custom makefile manager. This can take quite some time
during opening on large tree's.

> However, we still have bugs and wishlist requests that might also possibly 
> need attention. Let's also leave those bugs alone unless we actually fix them 
> on trunk.

Thats hardly possible, as most of the stuff in kdevelop3.4 is not
available in trunk/, for example the qmake manager.

> Feel free to comment on them or mark them as confirmed, but do not 
> close them. Just because they won't get done in the KDevelop 3.4 timeframe 
> doesn't mean that they won't need to be addressed in KDevelop 4. We can go 
> through the bug database at a later date and close the ones we don't do then 
> at that time.

I agree that we shouldn't go through the bug database now to close old
bugs or something like that. However for new bugs, especially things
that keep developers from doing their work (like crashes) should still
be adressed and fixed, IMHO. I plan to fix and commit at least one QM
bug and the fix for gcc filtering as well. Distributions tend to include
fixes from svn in their packages if they fix crashes or annoying bugs
(at least thats the case for Debian) and we have a few svn-users which
would benefit from these changes as well. 

So, while I do agree that major focus should be KDev4 and no new
features should be introduced into KDevelop3 I think major bugs (and
thats not just crashes) should still be looked at and if there's an easy
and small fix for them it should be committed (in the constraints of the
message freeze of course).

Andreas

-- 
You have a will that can be influenced by all with whom you come in contact.