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

[Pekka Paalanen]

On Sat, 9 Jul 2016 05:19:26 +0200 (CEST)
Jan Engelhardt <jengelh at inai.de> wrote:

> 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)

Hi,

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?

> >- 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)

I don't mind (anymore).

> - 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.

> - 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)

I'd like to avoid such confusion if possible, and use simply (the
to be when released) MAJOR  in the SONAME.

> 
> >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.

We have been bumping the project version to 1.y.90 right after the
release of 1.y.0, at the start of the development cycle. This way
unreleased projects can depend on our unreleased project.

> >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.

Indeed, yes.

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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160709/5d1c5fd1/attachment.sig>