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

[Emil Velikov]

On 7 July 2016 at 10:46, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 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.
>
If there were more developers, one could also move the tests into a
separate repo. Although that (plus libweston) would require extensive
audit of the private and public headers since atm, things are quite
fragile (one might even call them busted).

> 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
>
Don't think this is a serious problem, I've even recall people being
confused why they are still in sync.

> - 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?
>
This sounds like a good plan to me, fwiw.

> 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?
>
As mentioned elsewhere - one should not rely on development version of
project foo having stable interface(s). That said, making sure that
things aren't too crazy for people that do want to test them is a must
imho.
Nobody (?) wants to deter their testers away.

> This is starting to sound very much like what I read about GTK
> trying a new versioning scheme...
>
That might be a good idea. Are you talking about [1] [2] ?
Alternatively do you have a link/keywords on the topic ?

"Versionning - there's always more to it than one expects" ;-)

Thanks
Emil

[1] https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
[2] https://blogs.gnome.org/desrt/2016/06/14/gtk-5-0-is-not-gtk-5/