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

[Pekka Paalanen]

On Mon, 4 Jul 2016 16:25:54 +0100
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> On 4 July 2016 at 15:35, Quentin Glidic <sardemff7+wayland at sardemff7.net> wrote:
> > On 04/07/2016 16:23, Emil Velikov wrote:  
> >>
> >> From: Emil Velikov <emil.velikov at collabora.com>
> >>
> >> Signed-off-by: Emil Velikov <emil.velikov at collabora.com>
> >> ---
> >>  configure.ac              | 1 +
> >>  libweston/libweston.pc.in | 2 +-
> >>  2 files changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index be40f10..46b61ae 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
> >>  AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
> >>  AC_SUBST([WESTON_VERSION], [weston_version])
> >>  AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
> >> +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.
> >
> > When you have a project with a dep on libweston, you’ll have to dig the
> > weston version because the tarball is versioned as weston.
> >
> > I would only do that once (and if) we split libweston and weston to
> > different repositories.
> >  
> Yes splitting libweston into separate repo makes sense. Yet I failed
> to see where the actual pain is - there is a minor annoyance, and devs
> and/or distro maintainers have learned to deal with a lot nastier
> things through the years.
> 
> If anything, having libweston-2 provided by (a future)
> libweston-1.12.0 tarball/package would make things even more
> confusing/annoying. That is unless one is planning to say "f**k it,
> let's decrease the version" upon the split. With the later upsetting a
> lot of people.

Hi guys,

my 2c again:

I don't think splitting weston and libweston to separate
repositories can happen any time soon, because of the test suite
that is specific to weston. I do not want to duplicate the test
suite, and I do not want 'make check' in libweston to be useless,
so we need to keep them together for now.

I also think that we don't need separate versioning for weston and
libweston. Let's just use the same for both, now that the plans are
clarifying.

Yes, it does mean the following:

- weston version number will start to deviate from wayland, even
  when both are still released at the same time

- weston version number will be the same as libweston it uses

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

But, that's all fine with me, considering the confusion any other
scheme would raise.

I suppose (lib)weston release 1.12.0 would be last MAJOR=1 release
of weston, installing libweston-1.so, and then we'd just bump to
weston 2.0.0 on the next final release.

How's that?

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?

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?

This is starting to sound very much like what I read about GTK
trying a new versioning scheme...


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/20160707/b0c8a070/attachment-0001.sig>