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

Jan Engelhardt jengelh at inai.de
Sat Jul 9 03:19:26 UTC 2016


On Thursday 2016-07-07 11:46, Pekka Paalanen wrote:
>> >> +AC_SUBST([LIBWESTON_VERSION],
>> >> [libweston_major_version.libweston_minor_version.libweston_patch_version])  
>> >
>> > That makes packaging a pain. Although the whole libweston (supposedly
>> > parallel-installable) is already a pain.

First, what kind of parallel installability is sought?

* just runtime
* parallel development environment (like what e.g. libabw,
  librevenge.. do)

Few projects ever go to the length of making their /usr/include
headers or .pc files coinstallable by including some version number in
it.


>- MAJOR will start running like hell, we'll probably get to weston
>  27.0.0 before it slows down, or whatever

- do you care about release numbering? (Projects with equally high
  numbers don't anymore; like Chrome, Firefox, systemd)
- 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
- I imagine that no one cares about the SONAME either, so you could
  try banishing the SO version into the basename and getting away with
  it. Might cause $confusion.
  (libfoo 1.12: libfoo-2.so.0; libfoo 2.0 libfoo-4.so.0)

>Hmm... but again, if we use MAJOR like that, then during the
>development of 2.0.0 we would be still installing libweston-1.so
>because our version in git master is 1.12.90 until the first
>pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
>How to solve that? Or is it not a problem?

Some projects make the bump at the start of the development cycle,
some do it just before the tarball release, and some do it together
with the first incompatible change (i.e. midway).

To be really foolproof, every _commit_ that changes things in an
incompatible way would need a bump, but that is too much hassle for
most, so they just do it between tarball releases in one of the three
just-mentioned ways.

>The thing is, libweston 1.12.90 will be completely incompatible
>with libweston 1.12.0.
>
>Should .9x be a special case somehow, installed as
>libweston-1-90.so or such?

Since 1.12.90 is probably not incompatible to 1.13.0,
they both would install whatever 1.13.0 would have used.


More information about the wayland-devel mailing list