Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Saturday 2016-07-09 18:24, Pekka Paalanen wrote:
>> 
>> First, what kind of parallel installability is sought?
>> 
>> * just runtime
>> * parallel development environment (like what e.g. libabw,
>>   librevenge.. do)
>
>everything that is about libweston including development enviroment
>has been my idea.
>
>> Few projects ever go to the length of making their /usr/include
>> headers or .pc files coinstallable by including some version number in
>> it.
>
>Is there any particular downside of going all the way?

For example, if a program supports being built for gtk2 and gtk3,
it can't simply do
PKG_CHECK_MODULES([gtk], [gtk >= 2])
because the developers chose to stick the version in the basename :-(
Which means that someone has to do
PKG_CHECK_EXISTS([gtk-2.0], [PKG_CHECK_MODULES([gtk], [gtk-2.0])], [
PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
...repeat the fun...
])]

Now with gtk it was not so much a problem (yet!) because there
are only two different basenames in 15-or-so years.
But if weston wants to go to 27 "soon" (...)

>> >- MAJOR will start running like hell, we'll probably get to weston
>> >  27.0.0 before it slows down, or whatever  
>>
>> - if just parallel runtime is the goal: done deal, just bump
>>   the SO/ABI version (libfoo.so.2, .so.3), no one cares about
>>   how high they go
>
>We also have plugins and other stuff, to be scoped by installation
>directory.
>
>Wouldn't that cause installations to have a libfoo.so symlink
>without a version number? That we do not want, a too high risk of
>pointing to a wrong version.

The .so symlink is really only for /usr/bin/ld. It does not
play a role for ld.so (ld-linux.so.*) and therefore won't
interfere with plugins living in versioned directories.
(Cf. libmirage from cdemu)

>The point is, we need to define the libweston MAJOR to be used in
>installations separately from the project MAJOR, even if they will
>always match with releases, because they won't match during
>development.
>
>That's probably the simplest solution for starters. We could add
>configure.ac automation to use MAJOR+1 in the SONAME when project
>MICRO >= 90, too. Or maybe that will be MINOR >= 90 once we get to
>the habit of bumping MAJOR.

Or you can just have two lines in configure.ac next to each other
which will scream at you "update me in lockstep" everytime you look
at them because you modify one of them.

AC_INIT([libweston], [1.12.0])
libweston_SONUM=3
->
AC_INIT([libweston], [1.12.90])
libweston_SONUM=27