Bug 304020 - Come up with a standardised less-rubbish way of setting versions
Summary: Come up with a standardised less-rubbish way of setting versions
Status: RESOLVED FIXED
Alias: None
Product: telepathy
Classification: Unmaintained
Component: general (show other bugs)
Version: 0.4.0
Platform: unspecified Linux
: NOR normal
Target Milestone: Future
Assignee: Telepathy Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-24 18:31 UTC by David Edmundson
Modified: 2013-03-20 01:49 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 0.6.0
Sentry Crash Report:
ddomenichelli: Decision-Required+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Edmundson 2012-07-24 18:31:05 UTC
LightDM-KDE has a pretty good method, I suggest copying that.

Something like (in CMakeLists)

# Versions
set(KTP_VERSION_MAJOR 0)
set(KTP_VERSION_MINOR 2)
set(KTP_VERSION_PATCH 0)
set(KTP_VERSION ${KTP_VERSION_MAJOR}.${KTP_VERSION_MINOR}.${KTP_VERSION_PATCH})

then the rest is done with CMake's
configure_file
Comment 1 Daniele E. Domenichelli 2012-11-02 08:52:31 UTC
Not sure if related to this bug, but I'm sharing a few thoughts about versioning...

Do we want to force all components to run exactly the same common internals version (i.e. text-ui 0.5.2 require exactly common internals 0.5.2 at compile time and at run time) or do we want to leave less strict policy (i.e. text-ui 0.5.2 require common internals 0.5 for building and you can build it using 0.5.0 and run it with 0.5.3)?

At the moment we are allowing the latter option, but in this case we have to deal with 3 different version numbers:

1) Component version
2) Common Internals version (run time)
3) Common internals version (compile time)

At least the first 2 numbers might be required for debugging purposes, and should be in every bug report.

Moreover if each component has its version number, we will have to update it in every repository for every release.

We could try to make it less painful using some meta-repository + scripts, like in qt5 and releasing just one tarball but that would require a lot of initial work, even though it will probably save time in the long period.
Comment 2 David Edmundson 2012-11-02 09:46:24 UTC
There should be no ABI breaks between 0.5.x versions of common-internals or API additions (consider 3rd party apps using it, like webaccounts). Therefore knowing the compile time version is irrelevant. (right?)

I see no reason to restrict versions between 0.5.x releases to being the same, it will give us good practice for when we're a proper library. 

Though you're right at this point we do need to know the library version when dealing with bug reports if the bug in an app is caused by common-internals. I suggest a static method in the library that returns the version. Alternately ktp-debugger can have a version attached, which will always match common-internals.
Comment 3 Daniele E. Domenichelli 2012-11-02 11:16:19 UTC
(In reply to comment #2)
> There should be no ABI breaks between 0.5.x versions of common-internals or
> API additions (consider 3rd party apps using it, like webaccounts).
> Therefore knowing the compile time version is irrelevant. (right?)

Uh yes, that's right... but what if one 0.5 component can be compiled with common internal 0.4
I think that at the moment we are not doing any check on common internal version
Imho we should make a check in each component
   KTP_VERSION_MAJOR == KTP_{COMPONENT}_VERSION_MAJOR AND KTP_VERSION_MINOR == KTP_{COMPONENT}_VERSION_MINOR
in order to enforce that you need the same version

> I suggest a static method in the library that returns the version. 
I agree with the static method... something like "QString KTp::version()" should be enough, but if we need to make some checks we can add also "int KTp::versionMajor()", int KTp::versionMinor()" and "int KTp::versionPatch()"

We could use it in main() when setting the version so that we get it when you run xxxx --version.

At the moment the --version prints:

    $ ktp-contactlist --version
    Qt: 4.8.2
    KDE Development Platform: 4.8.4 (4.8.4)
    KDE Telepathy Contact List: 0.5.1

I'm not sure about the meaning of the KDE Development Platform version in brackets but perhaps we can have 0.5.1 (0.5.1) where the second version is the ktp-common-internals one.
Another interesting thing to print is tp-qt version...

Also Qt has some define to make checks at compile time... even I believe this is not necessary for us, it might be useful for someone else that wants to use the library and wants to support more than one version. I don't want to over-engineer this, but since we are deciding how to handle it, it is worth to have a look around at what the others are doing. Here are some useful links:
* http://qt-project.org/doc/qt-4.8/qtglobal.html
* http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/group__KDEMacros.html
* http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/namespaceKDE.html#aa7220767389d3c119ac8cf38bf333c55
Comment 4 David Edmundson 2013-03-20 01:49:39 UTC
Version number is now in the top level CMakeLists file for every repository, updating .desktop files too.