Future KDevelop 3.4.x releases

Matt Rogers mattr at kde.org
Thu May 24 21:46:21 UTC 2007


On Thursday 24 May 2007 16:28, Andreas Pakulat wrote:
> 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.
>

But we need to make sure that those things that are already documented as bugs 
don't occur in KDev4. If they don't/won't occur on trunk (after we've already 
implemented the affected bits of code) then we can say they're fixed for 
KDevelop 4. :)

> > 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

No problem with that. It's your free time after all. :) 
-- 
Matt




More information about the KDevelop-devel mailing list