Release Script

[Andreas Pakulat]

Hi,

On Thu, Jun 21, 2012 at 8:57 PM, Michael Jansen <info at michael-jansen.biz>wrote:

> **
>
> On Thursday, June 21, 2012 08:44:09 PM Andreas Pakulat wrote:
>
> > 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.
>
>
>
> And i am a bit confused too. As svuorela pointed out:
>
>
>
> objdump -x /kde4/kde/lib64/libkdepim-copy.so.4.8.0 | grep SONAME
>
> SONAME libkdepim-copy.so.4
>

The tldp link I included has a rather easy to understand explanation close
to the top about this.


> lrwxrwxrwx 1 mjansen users 19 May 23 19:31
>
> /kde4/kde/lib64/libkdepim-copy.so -> libkdepim-copy.so.4
>
> lrwxrwxrwx 1 mjansen users 23 May 23 19:31
>
> /kde4/kde/lib64/libkdepim-copy.so.4 -> libkdepim-copy.so.4.8.0
>
> -rwxr-xr-x 1 mjansen users 883382 Jun 16 22:32
>
> /kde4/kde/lib64/libkdepim-copy.so.4.8.0
>
>
>
> So i am not so sure about that stuff anymore. Or better i wasn't to start
> with.
>

As I said, right now most libs are at BC-version 4 (some kdelibs libs like
kdecore are already at BC version 5) and so far the minor version and a .0
was simply added to get the 'realname' (as tldp puts it).


> Anyway i don't want to change anything there. I just wanted to point out
> that reusing the number from kde4defaults.cmake should not be done for our
> packages.
>
>
>
> Each package should have each needed version information itself. Because
> only that makes it possible to skip releases and release independently.
>

Yes, if releasing projects indepentenly from one another is the goal, then
each needs to maintain its own SOVERSION and VERSION. FWIW some projects
already do this, kdevplatform for example is at SOVERSION 6 now in master
and kdegames also had two BC breakages since 2.0 I believe so it should
also be at 6 (didn't actually check and am not 100% sure).

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-buildsystem/attachments/20120621/6a53a746/attachment.html>