Which package will provide the common KDE library version number ?

[Kevin Ottens]

On Saturday 18 February 2012 17:50:28 Alexander Neundorf wrote:
> On Saturday 18 February 2012, Kevin Ottens wrote:
> > On Friday 17 February 2012 20:37:12 Sune Vuorela wrote:
> > > On 2012-02-17, Alexander Neundorf <neundorf at kde.org> wrote:
> > > > Do we still want a such a common version number ?
> > > > If yes, who (which file/package) should define it ?
> > > 
> > > No. It basically doesn't make sense. Also not in its current usage.
> > > 
> > > if I e.g. take a kdepimlibs 4.3 and build against kdelibs 4.8, all my
> > > pimlibs libraries are versioned like they were pimlibs4.8.
> > 
> > That behavior is indeed a problem. Still we need a way to ensure that we
> > have the same version number accross all frameworks when we release.
> 
> In general, when we build one git repository, it doesn't know anything about
> its environment, except:
> 1. the packages it depends on via find_package()
> 2. variables defined from the outside via -DFoo=foo
> 3. ...and environment variables
> 4. files existing somewhere relative to the source or build tree
> 
> For defining the library version numbers, somewhere must be something like:
> 
> set_target_properties(Foo PROPERTIES VERSION ${VERSION_NUMBER}
>                                      SOVERSION ${SOVERSION_NUMBER} )
> 
> These two version numbers should always have sensible values.
> I didn't test, but I'm not sure a libfoo.so.3dea0a0c6be9df8db4d01d6d5
> actually works.
> 
> Option 2) is basically out of the game because I am very sure we should not
> define the version number of a library via a command line parameter. Same
> for option 3.

Which leaves us the option 4 which is what I proposed in my previous email for 
release tarballs. You point out indeed a proper issue for the hash in version 
number for a library in the case of developer builds... We'd need to derive a 
proper version number in such case, not sure how.

> Seriously, if the libraries share something, which makes them "KDE
> frameworks libraries", then this something should exist.
> 
> Currently, this "something" seems to contain the shared version numbers, and
> the shared install directories.
> It's basically a file which specifies properties of "KDE frameworks"
> libraries.
> I.e. a package consisting more or less only of this one (cmake) file holding
> some properties.

Which would then recreate the problem Sune pointed out. Depending on which 
package got picked up you change the version number of the library even though 
the code base is the same.

So the other possibility would be to have the version number in the main 
CMakeLists.txt of each framework which raises potential consistency issues... 
Solution would then be that the scripts used to generate the release tarballs 
verify the version is properly set everywhere.

I really think the solution lies in the way we execute the release, not at 
build time.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120218/0e577793/attachment.sig>