Release Script

[Michael Jansen]

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

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.

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.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20120621/d4daa7f2/attachment-0001.html>