On Sunday 02 October 2011 18:36:14 Allen Winter wrote:
Howdy,
A lot of CMakeLists.txt use the ${GENERIC_LIB_VERSION} to set the so
versioning of their libraries.
That variable is hard-coded in kdelibs/cmake/modules/KDE4Defaults.cmake
If we rely on kdelibs-4.7 for the KDE SC 4.8 release,
On Monday 03 October 2011, Allen Winter wrote:
Howdy,
A lot of CMakeLists.txt use the ${GENERIC_LIB_VERSION} to set the so
versioning of their libraries. That variable is hard-coded in
kdelibs/cmake/modules/KDE4Defaults.cmake
If we rely on kdelibs-4.7 for the KDE SC 4.8 release, then all
A Dilluns, 3 d'octubre de 2011, Alexander Neundorf vàreu escriure:
On Monday 03 October 2011, Allen Winter wrote:
Howdy,
A lot of CMakeLists.txt use the ${GENERIC_LIB_VERSION} to set the so
versioning of their libraries. That variable is hard-coded in
On Monday 03 October 2011 5:04:45 AM Albert Astals Cid wrote:
A Dilluns, 3 d'octubre de 2011, Alexander Neundorf vàreu escriure:
On Monday 03 October 2011, Allen Winter wrote:
Howdy,
A lot of CMakeLists.txt use the ${GENERIC_LIB_VERSION} to set the so
versioning of their libraries.
On 2011-10-03, Allen Winter win...@kde.org wrote:
On Monday 03 October 2011 5:04:45 AM Albert Astals Cid wrote:
A Dilluns, 3 d'octubre de 2011, Alexander Neundorf vàreu escriure:
On Monday 03 October 2011, Allen Winter wrote:
Howdy,
A lot of CMakeLists.txt use the
Martin Gräßlin wrote:
If it's only for bug fixes, wouldn't it be easier to branch 4.8 from 4.7?
That way only two instead of three branches have to be maintained. If we
open master for 4.8 development again (even only for bugfixes), I fear we
will have much discussions again about adding
Am Mon, 03 Oct 2011 21:37:51 +0200
schrieb Kevin Kofler kevin.kof...@chello.at:
Martin Gräßlin wrote:
I don't want to have lengthy threads on kcd
each other week were developers state how evil KDE is by not
letting them include their awesome feature NOW.
making fun of volunteers trying to
Thomas Lübking wrote:
So what's the big difference?
The big difference is that kdelibs 4 and KDE Frameworks 5 are different
(sets of) libraries with incompatible APIs which will be shipped alongside
each other in distributions for years. So this is not a normal freeze, it's
a permanent freeze
Am Mon, 03 Oct 2011 22:41:11 +0200
schrieb Kevin Kofler kevin.kof...@chello.at:
The big difference is that kdelibs 4 and KDE Frameworks 5 are
different (sets of) libraries with incompatible APIs which will be
shipped alongside each other in distributions for years. So this is
not a normal
Thomas Lübking wrote:
In this case porting would be recompiling and relinking, so if one
desperately wants a new feature in an application (since libraries
don't have features for their own sake) one would just port to the
KDE5 frameworks, yesno?
Not if the application is using deprecated
Am Mon, 03 Oct 2011 23:11:18 +0200
schrieb Kevin Kofler kevin.kof...@chello.at:
Not if the application is using deprecated APIs, including but not
limited to Qt3Support and kde3support.
I always though that'd be the reason for the deprecated tag.
Hey developer: get rid of this call, asap!
(And
11 matches
Mail list logo
