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

[Andreas Pakulat]

On 15.06.10 12:29:03, Milian Wolff wrote:
> On Tuesday 15 June 2010 12:24:22 David Nolden wrote:
> > 2010/6/15 Andreas Pakulat <apaku at gmx.de>:
> > > On 15.06.10 11:34:54, David Nolden wrote:
> > >> 2010/6/1 Andreas Pakulat <apaku at gmx.de>:
> > >> > Well, it hinders my personal development a bit as I have only trunk on
> > >> > one machine and the others all still run 4.3 (there are updates
> > >> > available but I don't have the time to do that currently, especially
> > >> > handle all the possible breakages).
> > >> > 
> > >> > And I fear I'm not the only one in this position.
> > >> 
> > >> Very soon (after I'm ready with the SmartRange -> MovingRange
> > >> porting), our trunk will anyway depend on kdelibs trunk and later
> > >> kdelibs 4.5, so soon there will be no way around updating kdelibs for
> > >> developers.
> > > 
> > > Can we please postpone merging that branch until 4.5.0 is released? It'll
> > > be quite a major change anyway, so lets depend on a released version
> > > instead of some in-development-stuff (after all thats one of the points
> > > of using feature-branches).
> > 
> > But this is a such big change that I would want it to be in trunk as
> > early as possible, so we have no merge conflicts in future, and so it
> > can start stabilizing _early_ until we have our next release.
> > 
> > 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.

> > 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'd rather propose for those who want to be compatible with KDE 4.4 to
> > branch of KDevelop 4.0, and then merge changes upwards into trunk if
> > possible.

Its not about being compatible with 4.4, its about being able to work with
master on systems where I don't have the time/capacity to build from trunk
every other day.
 
> And guys, it's rather easy to get Kate from 4.5 setup nowadays thanks to the 
> Kate on Git repo:
> 
> http://gitorious.org/kate
> 
> All you need to do in order to link against it properly is symlinking it's 
> headers (dunno about the libs) into your (maybe stable) kdelibs. I do that 
> since some time and it works like a charm.

That doesn't change the KDE version, hence I'd need to add a hack to
kdevelop's cmake files to make it accept KDE 4.4 locally. Sorry, not going
to happen.

Andreas

-- 
There is a fly on your nose.