[kdevplatform] d3af706 Increase KDE requirement to 4.4 to fix the build f

[Andreas Pakulat]

On 15.06.10 14:06:31, David Nolden wrote:
> 2010/6/15 Andreas Pakulat <apaku at gmx.de>:
> >> > I think feature branches are something for "optional" features that
> >> > can be merged, or not merged, but this change is vital to KDevelop,
> >
> > I disagree on that. feature branches are for developing stuff until its
> > ready to be merged into master, no matter wether its something thats to be
> > merged anyway or not.
> 
> I'm not planning to commit it before it's ready, but like any new
> code, of course it will contain issues, especially because it will
> also use completely new kate code. However having it in trunk instead
> of in a branch will help to notice those issues faster, and since this
> code will be merged anyway, it doesn't make sense to hold it back just
> to notice the issues later rather than earlier.

IMHO you're wrong, or rather you didn't grasp yet how one usually works
with git. The point is that you can just let us know the public branch
where this code resides and we can easily grab it, merge it locally into a
branch and use it, reporting bugs or fixing issues. There's no necessity to
put this into master and hence causing all that pain for normal users that
use master (for whatever reason).

> >> > and should go in as soon as it's functional. Also language-plugin
> >> > developers need time to adapt their language plugins, and it's better
> >> > for anyone to work on "current" code rather than code that's already
> >> > superseded. After all, that's what "trunk" is for, no?
> >
> > So you're planning a release of 4.1 in the next six months? Or why is
> > waiting 6 weeks (roughly) a problem? Testing it as much as possible means
> > moving the release date (which doesn't even exist yet) further away, not
> > cramping in new stuff that only few people can actually compile asap.
> 
> I think we _must_ release close to the KDE 4.5 is release, else it
> won't be possible to have a well-running KDevelop on top of KDE 4.5.
> Current KDevelop on KDE 4.5 is way too unstable to be acceptable by my
> measures (too many crashes in SmartRange due to the change frenzy in
> kate).

Thats completely unrealistic, 4.5 is to be released in 6 weeks. Even
releasing in 8 weeks is nothing you can pull off. Let alone that there's
been only very little feature development done which would warrant a new
minor release. Oh and there's Aleix code which will be merged until then
most probably that also needs testing etc.

I've worked with kdevelop yesterday 5 hours straight (against a 2 or 3
weeks old kdelibs/kate trunk) and had a single crash (which was the
buildjob problem). Its not rock-solid, but looking at our bugreports 4.0
isn't rock solid on KDE 4.4 either.

So yeah, I strongly object that idea.

> I know it's annoying to raise the requirements of the development
> version, but you've done the same for much less important reasons in
> the KDevelop 4.0 development cycle..

The point is not about raising per se, the point is about rainsing to an
unreleased version as that means getting packages is not easy.

Anyway, this already getting annoying again, I'll just fork off master if
the requirement is raised and I can't update my machines with packages.

Andreas 

-- 
Reply hazy, ask again later.