Release Script

[Andreas Pakulat]

Hi,

On Thu, Jun 21, 2012 at 7:58 PM, Michael Jansen <info at michael-jansen.biz>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 <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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120621/609d6f3b/attachment.html>