KDevelop 4.0 Release

[Andreas Pakulat]

On 08.09.08 01:00:13, Manuel Breugelmans wrote:
> On Sunday 07 September 2008 20:58:49 Andreas Pakulat wrote:
> > Hi,
> >
> > yes its that time of the year again, while KDE 4.1 has "just" been
> > released that Release team decided that a KDE 4.2 release happening
> > earlier would be good (reasoning is to release KDE 4.3 earlier so it
> > happens before akademy next year). Details on the release plans can be
> > found here:
> >
> > http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule
> > http://techbase.kde.org/Schedules/KDE4/4.3_Release_Schedule
> >
> > If you look at the 4.2 plan closely you'll notice that it gives us not
> > even 2 months of feature-development (provided that we put all our stuff
> > into the feature plan before that).
> >
> > The question I have is: Do we feel we can make that for our 4.0 release,
> > without having to tell everybody that "yeah, 4.0 is kind of an
> > early-adopters release, so expect a lot of bugs and missing features".
> >
> 
> I'm going to have to go with the flow here, release is definitely a good idea. 
> That being said calling it 4.0 would be a mistake, it just misses way too much 
> stuff at the moment. I'd say make it a beta, but a granite one ;-)

Thats my personal feeling too, I don't see us pulling a 4.0 release but
a solid Beta could be released "anytime" now.

> Is it actually necessary to follow KDE release schedules?

Not technically, we did do our own releases in KDevelop3 times once or
twice. However releasing with KDE gives us:

- less work, regarding creation and testing of tarballs
- more "publicity" as we'd be mentioned in the release notes
- a better reason to stay as main KDE module (kdevelop being in KDE/
  means we should follow KDE release cycles, else we should be in
  extragear)
 
> Needed before a release is possible:
> - DUChain robustness; still too much Q_ASSERT(bucket _size) for me. It's 
> unacceptable to require 'rm -rf ~/.kdevduchain' all the time

I did have to remove .kdevduchain lately, after one of Davids commits
which clearly stated so. But other than that I do get pretty little
crashes because of those parts.

> - Cleanup and extension of New App wizard, this is what new users are going to 
> try ... should work flawlessly

The plan is to work on that as soon as annma is back because we need to
fix the co-existence of kdesdk app-templates and our own ones.

> - Better 'new file' support! I find myself using the integrated konsole for 
> this.

There's multiple things here. One is that we don't have the templates
stuff, the next is that this template-stuff needs to be integrateable
into class-wizard and things like that. The last is that cmake (or qmake
or custom makefiles) don't support the projectfilemanagement interface.

And thats one of the reasons I don't see us making the cut for 4.2.

> - List of plugins that are (i) tested (ii) usable (iii) being used. Anything 
> that doesn't qualify on those criteria should not be shipped, imo.

You mean 'tested' as in covered by automated tests or as in I'm using
this all day long. I think almost all plugins qualify for the latter,
except bazaar, mercurial and cvs support (oh and those experiments like
duchainviewer). All of them obvously need to go to playground before a
release.

> Maybe it'd be good to have a set of use cases / user stories and focus on 
> completing those.

Thats exactly the stuff the usability folk could help with, but I fear
they might not have the needed expertise about developers. After all
they're not the "average" desktop users...

Andreas

-- 
You will remember something that you should not have forgotten.