DevHeads.net

kdelibs 4.8? What to do about GENERIC_LIB_VERSION?

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?

Comments

Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?

By Alexander Neundorf at 10/03/2011 - 03:56

On Monday 03 October 2011, Allen Winter wrote:
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.

We'll basically do this in the frameworks branch.

Alex

Re: Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?

By Albert Astals Cid at 10/03/2011 - 04:04

A Dilluns, 3 d'octubre de 2011, Alexander Neundorf vàreu escriure:
Third time in this thread. This is Dirk's plan all along.

Albert

Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?

By Allen Winter at 10/03/2011 - 07:45

On Monday 03 October 2011 5:04:45 AM Albert Astals Cid wrote:

Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?

By todd rme at 10/03/2011 - 09:14

On Mon, Oct 3, 2011 at 2:45 PM, Allen Winter < ... at kde dot org> wrote:
Shouldn't this track the pre-release numbering once we have some
pre-releases (like 4.7.85 or something)?

-Todd

Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?

By Sune Vuorela at 10/03/2011 - 08:37

On 2011-10-03, Allen Winter < ... at kde dot org> wrote:
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?

By Allen Winter at 10/03/2011 - 09:17

On Monday 03 October 2011 9:37:51 AM Sune Vuorela wrote:

Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?

By Martin =?ISO-88... at 10/03/2011 - 01:02

On Sunday 02 October 2011 18:36:14 Allen Winter wrote:
Cheers
Martin

Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?

By Kevin Kofler at 10/03/2011 - 14:37

Martin Gräßlin wrote:
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?

By =?utf-8?Q?Thoma... at 10/03/2011 - 14:57

Am Mon, 03 Oct 2011 21:37:51 +0200
schrieb Kevin Kofler <kevin. ... at chello dot at>:

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?

By Kevin Kofler at 10/03/2011 - 15:41

Thomas Lübking wrote:
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?

By =?utf-8?Q?Thoma... at 10/03/2011 - 16:07

Am Mon, 03 Oct 2011 22:41:11 +0200
schrieb Kevin Kofler <kevin. ... at chello dot at>:
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?

By Kevin Kofler at 10/03/2011 - 16:11

Thomas Lübking wrote:
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?

By =?utf-8?Q?Thoma... at 10/03/2011 - 16:22

Am Mon, 03 Oct 2011 23:11:18 +0200
schrieb Kevin Kofler <kevin. ... at chello dot at>:
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