Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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, then all the shared
libraries using ${GENERIC_LIB_VERSION} will
be still set to 4.7. for example the kdepimlbs kcalcore library will be
versioned to 4.7.0 instead of 4.8.0 in the KDE SC 4.8
release.
So... seems to me we will need a kdelibs 4.8 or perhaps we make kdelibs/cmake
into a kde-buildsystem package
Personally, I'd like to see kdelibs master opened up again for bug fixes only.
Remind me again why we can't do that and just keep an eye that no new
features get in?
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 features to it. 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.
Cheers
Martin
signature.asc
Description: This is a digitally signed message part.
Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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 the shared
libraries using ${GENERIC_LIB_VERSION} will be still set to 4.7. for
example the kdepimlbs kcalcore library will be versioned to 4.7.0 instead
of 4.8.0 in the KDE SC 4.8 release.
How about simply increasing the version number to 4.8 ?
This would also give the libs in kdelibs the version number 4.8, but I don't
see a problem with that.
So... seems to me we will need a kdelibs 4.8 or perhaps we make
kdelibs/cmake into a kde-buildsystem package
We'll basically do this in the frameworks branch.
Alex
Re: Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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
kdelibs/cmake/modules/KDE4Defaults.cmake
If we rely on kdelibs-4.7 for the KDE SC 4.8 release, then all the
shared
libraries using ${GENERIC_LIB_VERSION} will be still set to 4.7. for
example the kdepimlbs kcalcore library will be versioned to 4.7.0
instead
of 4.8.0 in the KDE SC 4.8 release.
How about simply increasing the version number to 4.8 ?
This would also give the libs in kdelibs the version number 4.8, but I don't
see a problem with that.
Third time in this thread. This is Dirk's plan all along.
Albert
So... seems to me we will need a kdelibs 4.8 or perhaps we make
kdelibs/cmake into a kde-buildsystem package
We'll basically do this in the frameworks branch.
Alex
Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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. 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 the
shared
libraries using ${GENERIC_LIB_VERSION} will be still set to 4.7. for
example the kdepimlbs kcalcore library will be versioned to 4.7.0
instead
of 4.8.0 in the KDE SC 4.8 release.
How about simply increasing the version number to 4.8 ?
This would also give the libs in kdelibs the version number 4.8, but I don't
see a problem with that.
Third time in this thread. This is Dirk's plan all along.
Ok then.
If there are no objections I will increase the variables in kdelibs-4.7 to say
4.8
Albert
So... seems to me we will need a kdelibs 4.8 or perhaps we make
kdelibs/cmake into a kde-buildsystem package
We'll basically do this in the frameworks branch.
Alex
Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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 ${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 the
shared
libraries using ${GENERIC_LIB_VERSION} will be still set to 4.7. for
example the kdepimlbs kcalcore library will be versioned to 4.7.0
instead
of 4.8.0 in the KDE SC 4.8 release.
How about simply increasing the version number to 4.8 ?
This would also give the libs in kdelibs the version number 4.8, but I
don't
see a problem with that.
Third time in this thread. This is Dirk's plan all along.
Ok then.
If there are no objections I will increase the variables in kdelibs-4.7 to
say 4.8
erm. I think it was the plan to do it when we are about to release 4.8.
not now.
/Sune
Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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 features to it. 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. Surely making fun of volunteers trying to contribute features to KDE software and failing because of a stupid bureaucratic policy is NOT the way to encourage more contributions to the KDE projects… Kevin Kofler
Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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 contribute features to KDE failing because of a stupid bureaucratic policy [...] a) Given the recent flamewars on kde-devel i don't see any fun in Martin's statement :-( b) I guess you got the moving target on a moving target part, did you? As much as i understood the kdelibs freeze is there to keep workload under control and kdelibs frameworks in sync during the transition, I've so far not seen a counterproof and that's not my interpretation of bureaucratic. There've always been freezes and they always suck when you want to push sth. This freeze is gonna take a little longer and you just push afterwards as well. So what's the big difference? Cheers, Thomas
Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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 of kdelibs 4. Kevin Kofler
Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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 freeze, it's a permanent freeze of kdelibs 4. a) I guess i would not be a big deal to backport features once the transition is done and the frameworks tagged ABI stable (iff there's requirement for adding features to 4.7), ie. just re-open kdelibs4 then (there's really no justification but strategical reasons in denying that, iff it has been denied - what i would have missed) The question would rather be who will maintain KDE4 then and what makes features not added this weak more important than feature not added next year because kdelibs4 is in maintenance mode. b) As far as I understood, KDE5 is more about disintegrating kdelibs and the unavoidable ABI break is just a welcome occasion to tidy up API, but API breaks are not the driving factor and will in general remain far below KDE3 - KDE4. 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? Cheers, Thomas
Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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 APIs, including but not limited to Qt3Support and kde3support. Kevin Kofler
Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
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 i will not comment on software that for the last 5-6 years didn't get rid of the [Qt|kde]3Support stuff. Inb4 you cheer in triumph: bespin only links it in order to be able to style such applications as well, which -yes- exist. Far too many, imho.) Cheers, Thomas
