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

[Milian Wolff]

On Tuesday 15 June 2010 12:52:43 Andreas Pakulat wrote:
> 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.

hm true I forgot that.

David, you could simply publish your branch on our team repos:
http://gitorious.org/+kdevelop-developers

I'll test your branch for sure.

Bye
-- 
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/165e9446/attachment.sig>