Release Script

Michael Jansen 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:
> Hi,
> 
> On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen <info at michael-
jansen.biz>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.


-- 
Michael Jansen
http://michael-jansen.biz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120621/46fd5414/attachment-0001.html>


More information about the release-team mailing list