Qt 5 (Re: [kdelibs/frameworks] kdeui/tests: Remove QEXPECT_FAIL for MR 43915)

[Albert Astals Cid]

El Dilluns, 14 de gener de 2013, a les 14:37:49, David Faure va escriure:
> On Sunday 13 January 2013 14:21:05 Jon Severinsson wrote:
> > I was under the impression that dropping Qt4 support was in favour of Qt5
> > released tarballs, eg that we would support both latest 5.0.x and 5.1-git
> > (currently dev, eventually stable) for a while (ie until 5.1.0-rc1). I'm
> > currently running stable with manual merges from release btw.
> 
> When I discussed it with Kévin, he made me realize that this would mean
> quite some trouble to support both versions, for no good purpose.
> E.g. we won't be able to use all the stuff that I'm working on putting into
> 5.1 -- or only optionally, which means no cutting of dependencies, so we'll
> still be somewhat stuck like we are right now, on some aspects.
> 
> If one compiles his own Qt 5, one might as well compile the dev branch.

That is true, but i expect now that Qt 5 is release a lot of distros might 
start adding 5.0.x packages, we have to consider the cost/benefit of requiring 
dev against requiring packages that might be easier to get. OTOH if we need 
stuff in dev, we need stuff in dev and there's not much more we can do :D

Cheers,
  Albert

P.S: Yes i know i said almost nothing, sorry :-/

> 
> 
> On top of that, the version numbers being equal between stable and dev in
> Qt5 right now makes it in fact impossible to use ifdefs to differenciate
> them :)
> > > So I asked that build.kde.org tracks dev.
> > 
> > Sounds reasonable for the mid term (once dev starts accepting 5.2 features
> > it should probably track stable instead)
> 
> Yes.
> 
> > but for now it should preferably
> > track some private tree in which you manually merge the release (and
> > stable) submodule heads that are referenced in qt5.git.
> 
> Not sure I follow that.
> 
> I think we should just track qt5.git "dev".
> 
> Right now it's missing a few bugfixes (like the MR in this thread), but I
> just solved that (with a big ifdef that disables that test until the dev
> branch is called 5.1). At the current stage of KF5 development, we need the
> newest API more than we need the newest bugfixes...