Review Request 113373: Enable C++11 support by default.

[Kevin Ottens]

On Friday 25 October 2013 11:38:40 Stephen Kelly wrote:
> Kevin Ottens wrote:
> >> That could obsolete ecm_mark_as_test etc.
> > 
> > Sure, I don't see how that's different from classes or methods we have in
> > our libraries at the moment which will get obsoleted by some later Qt
> > version. With that line of thinking we'd never release.
> > 
> > Just mark modules which gets obsoleted as deprecated... Or I'm missing
> > something?
> 
> /shrug/ It's your call.
> 
> My opinion is that releasing a fork of something that's already in cmake
> master is not a good idea. Will the CMake version override the fork when it
> is released? That file will be in a CMake release early next year I guess.

Well, yes, I agree exact forks are a problem... They should at least have a 
different name IMO. For instance ecm_mark_as_test is doing the right thing, 
there's no risk of clash later on.

So if we have things which present this risk of clash, we probably need to 
rename them ASAP.
 
> Sure, that's after you want to release karchive and threadweaver, but before
> everything else.

I think that we just disagree on the timing really, by its nature I think ECM 
should go first, even though at the last possible moment... so that'd be with 
the tp1 containing karchive and threadweaver. I've no problem with that 
particular release of ECM being marked as TP or Alpha if you want. That still 
leaves you free to change the interface until we get to release more of KF5... 
it could follow a similar cycle.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

Sponsored by KDAB to work on KDE Frameworks
KDAB - proud supporter of KDE, http://www.kdab.com

-------------- 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/kde-frameworks-devel/attachments/20131025/45ed618a/attachment.sig>