Commit 57d49192 authored by Jiří Techet's avatar Jiří Techet

Fix incorrect format of library version in meson

parent cc66af7d
......@@ -25,13 +25,13 @@ else
endif
# Before making a release, the LT_VERSION string should be modified.
# The string is of the form C.R.A.
# The string is of the form C.A.R
# - If the interface is the same as the previous version, change to C.A.R+1
# - If interfaces have been changed or added, but binary compatibility has
# been preserved, change to C+1.0.A+1
# been preserved, change to C.A+1.R
  • And this one should be C.A+1.0, right? (Not sure by myself any more, who would have thought adding 1 could be so difficult ;-)

  • Yes.

    The commit I'm preparing just takes the same string as configure.ac (C:R:A) and turns it into C-A.A.R for the lib version.

  • Perfect, thanks!

Please register or sign in to reply
# - If binary compatibility has been broken (eg removed or changed interfaces)
# change to C+1.0.0
Please register or sign in to reply
# - If the interface is the same as the previous version, change to C.R+1.A
lib_version = '11.7.11'
lib_version = '0.11.7'
package_name = meson.project_name().strip('lib')
package_string = '@0@-@1@'.format(package_name, api_version)
......
  • Right. ABI probably won't change but good to have it right.

    (Just wondering, is there any reason for this way of numbering? If ABI change did just C+1.0.0, would it cause some problems?)

  • We're doing all this just because we want to ensure that autotools and meson produce the same versions. Autotools uses Libtool's weird current:revision:age scheme to specify a compact set of "interface versions" which are supported, which is then translated to the system's actual versioning scheme. If we were using only Meson we could use the latter directly.

    I guess this is just a boatload of legacy-ness. https://www.gnu.org/software/libtool/manual/libtool.html#Versioning

    Edited by Jan Alexander Steffens
  • Well, I plan to remove the autotools (see !4 (closed)) so the question is whether doing C+1.0.0 wouldn't be nicer when we won't have to care about autotools.

    Again, in reality there probably won't be an ABI change in the libchamplain-0.12.so library. In the future there could be a "stable" release without the version as part of the library name (libchamplain.so) and the necessary ABI changes could be made then.

  • If we're throwing autotools away anyway, how about just using the project version, then? That would make the next libchamplain release have libchamplain-0.12.so.0.12.19.

    At some point this could become libchamplain.so.1.0.0.

  • Hmm, I think the filename should reflect API/ABI compatibility changes. With such naming you won't know whether an application linked against libchamplain-0.12.so.0.12.19 can be used on a system with libchamplain-0.12.so.0.12.18 because you don't know whether there was an API addition between the releases or not and whether the application doesn't use the new API.

  • Hmm, true. I'll leave the libtool-style versioning in place in my MR for now. This can be revisited later.

Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment