--===============0389959996775858328== Content-Type: multipart/signed; boundary="nextPart1798615.adxPqhOjU1"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart1798615.adxPqhOjU1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hello people, As planned, we had the "KF5 in Release Mode" BoF at Akademy. Quite a lo= t of=20 information on the current status got shared, but I'm not going to focu= s on=20 that in this email. I'm writing this email to let everyone know about t= he two=20 main novelties which got discussed during this meeting. First topic is about the C++11 support in KF5. Volker added an email ab= out=20 that, but I thought I'd run through it again. So far, no C++11 feature = was=20 used in KF5. The default rule on that topic was "let's do it the same w= ay than=20 Qt" since one of the main goals of KF5 is to make our technologies desi= rable=20 for Qt application developers. After revisiting how it is done in Qt, i= t turns=20 out that the situation there is less than clear... We agreed on support= ing the=20 following minimal versions for the compilers: gcc 4.5, clang 3.1 and VS= 2010. That means the new rule is as follow: * We're not supporting the full extent of C++11 in KF5 (although I enc= ourage=20 people to use more higher up in the stack); * We're white listing some of the C++11 features in KF5, namely are no= w=20 allowed: - auto; - rvalue support (except for "*this"); - lambdas. * If you want to use more than the above: - it must be made optional by the use of #ifdef or the Q_* macros (e= .g.=20 Q_DECL_OVERRIDE); - both the binaries built with or without those extra features must = be=20 binary compatible. Note I also added the above to the policies for Frameworks: http://community.kde.org/Frameworks/Policies#Frameworks_compiler_requir= ements_and_C.2B.2B11 Second topic, more to the point of the BoF, is about getting ourselves = in=20 release mode. The situation in KF5 is getting clearer by the day and as= such=20 we're seeing progress toward meeting a releasable state. This is why we= 've=20 been already filtering the type of tasks we distribute to focus only on= the=20 "must have" tasks. Every other type of tasks are put on a waiting list = for=20 post 5.0 work. With this ongoing shift of strategy and mindset, we can play a bit the=20= prediction game. At the current pace and amount of effort put into the=20= project, it is feasible to roll out a technology preview in December 20= 13=20 latest with a good confidence level. If the tooling supports it, that preview probably won't be released in = one go=20 but in batches (to be confirmed later) in order to find the problems al= ong the=20 way. With such a strategy we might be able to be very close to a final = release=20 in March 2014. It's clearly not a given, we'll reevaluate in December if we're still o= n=20 track, as you know in volunteer projects the amount of available effort= can=20 vary greatly (and those estimates assume it will be constant). Still, t= hat=20 makes March 2014 a very worthwhile goal to pursue, so let's try to meet= it=20 nonetheless. That's it for now, thanks for your attention. Regards. --=20 K=E9vin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com --nextPart1798615.adxPqhOjU1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEABECAAYFAlHtDLgACgkQB0u7y43syeJcIACfVbEh8MvAx1Wl26L4s4ar/glx Wv4AoKQFmZqtsem2+vfkibIKcJNVOor2 =KVjg -----END PGP SIGNATURE----- --nextPart1798615.adxPqhOjU1-- --===============0389959996775858328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel --===============0389959996775858328==--