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

[Milian Wolff]

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,
> 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?
> 
> 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.

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.

Bye

PS: I'm also for testing that as much as possible.
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100615/e81ed0ce/attachment.sig>