Hi, On Thu, Jun 21, 2012 at 7:58 PM, Michael Jansen <[email protected]>wrote:
> ** > > On Wednesday, June 20, 2012 11:56:51 PM Andreas Pakulat wrote: > > > Hi, > > > > > > On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen <[email protected] > >wrote: > > > > 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 our packagers. > > > > 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. > Hmm, I may have to retract here, it seems my mail was led by false assumptions based on the shared libs I have here. So, I now think that generating the second and third digit of the version from a file automatically, so it matches the minor and bugfix version of the project that the shared library belongs to is just fine. As far as I can see from http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html the soversion and the first digit of the three-digit version number need to match. Since you don't want to update the soversion automatically as it has far-reaching consequences to do that, that part should not be auto-generated for the VERSION property. So read out minor and bugfix version and append that to the SOVERSION property to create a value for VERSION in cmake. Andreas
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
