info at michael-jansen.biz
Thu Jun 21 17:58:58 UTC 2012
On Wednesday, June 20, 2012 11:56:51 PM Andreas Pakulat wrote:
> On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen <info at michael-
> > 2. Make the necessary build-system changes to use this version information
> > for the .SO names.
> IMHO this is wrong, the numbers tagged to the end of a shared-object thats
> used as a shared library really have nothing to do with the release version
> number. The number is only used to distinguish compatibility of different
> release of the same library.
I do not disagree. But this is how it is currently done unless i am mistaken.
Which is certainly possible.
So unless someone comes up with a better solution or explains why and how i am
wrong i will keep that because i am pretty sure requiring people to manually
update the soname for each release is a recipe to disaster and a way to annoy
But if you have a solution or idea for that? Keep it coming. We could define
the soversion too in that configuration file. But how and when to increase? On
each major and minor release increase it automatically too?
Btw. kdelibs/cmake/modules/KDE4Defaults.cmake:22 ++
> And you cannot really go back to 4.2.0 now that 4.9.0 is going to be
> released. The only option would be to move forward to 5.2.0. So still no
> exact match between release-version and soname.
I don't want to go back. kdepim4.x will always use the kdelibs versions for
its soname and not its own version. Unless we rerelease it i can't and don't
want to change that.
So the sonames we are talking of are 4.1x or 5.0 depending on the versions we
put the changes live.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kde-buildsystem