Summary: | Come up with a standardised less-rubbish way of setting versions | ||
---|---|---|---|
Product: | [Unmaintained] telepathy | Reporter: | David Edmundson <kde> |
Component: | general | Assignee: | Telepathy Bugs <kde-telepathy-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ddomenichelli |
Priority: | NOR | Flags: | ddomenichelli:
Decision-Required+
|
Version: | 0.4.0 | ||
Target Milestone: | Future | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 0.6.0 | |
Sentry Crash Report: |
Description
David Edmundson
2012-07-24 18:31:05 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. 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. (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 Version number is now in the top level CMakeLists file for every repository, updating .desktop files too. |