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

[Emil Velikov]

On 9 July 2016 at 17:26, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Thu, 7 Jul 2016 17:45:24 +0100
> Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
>> 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).
>
> More developers or not, I am not so optimistic that it would work.
>
> The tests have code intimately tied to internal APIs of both weston
> and libweston. That alone is reason enough. It may not even be
> possible to get rid of that, realistically.
>
> To be able to run libweston, we'd essentially need a copy of weston
> anyway, for initializing it.
>
Had no idea about those. I'd imagine that one could handle those with
git submodules, although that might be a bit fragile and it'll require
a ton more development effort that there is atm.

Just food for though, than a serious suggestion.

>> > 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.
>
> Heh, cool.
>
>> > - 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.
>
> Alright.
>
>> > 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 issue is being discussed in my reply to Jan, so I'd prefer to
> continue in that part of the thread.
>
>> > 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/
>
> Reference [1] is what I had in mind. However, I'd probably not have
> a "random" MINOR version declared as the final API/ABI of the
> MAJOR. As I don't mind MAJOR running to high numbers, I'd prefer to
> have MAJOR bump signify API/ABI breaks like people would
> usually expect. Right?
>
Precisely. Running into high MAJOR shouldn't be an issue, plus there
aren't as many users of libweston (as they are for GTK), that the API
will require the long period of definition (to mature).

> I just read [2] for the first time. The difference is IMO that we
> don't have a schedule or a plan (yet) like GTK has for cutting
> stable releases. Getting Weston/libweston forward is already painful
> enough that I don't want to care about breaking things, let's just
> bump MAJOR every time. We also don't do the odd/even versioning,
> and I don't think we have a user like GNOME is for GTK in that
> you'd need sort-of-stable-but-not-really releases - breaking
> backward compat with each release is what we will do for a long
> time.
>
Ack, makes perfect sense, imho.

-Emil