kdelibs 4.8? What to do about GENERIC_LIB_VERSION?

[Martin Gräßlin]

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
-------------- 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-core-devel/attachments/20111003/dfb9ae95/attachment.sig>