On Mon, 4 Jul 2016 16:25:54 +0100 Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 4 July 2016 at 15:35, Quentin Glidic <sardemff7+wayl...@sardemff7.net> > wrote: > > On 04/07/2016 16:23, Emil Velikov wrote: > >> > >> From: Emil Velikov <emil.veli...@collabora.com> > >> > >> Signed-off-by: Emil Velikov <emil.veli...@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
pgpBTiQFbuFOb.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel