On Sat, 9 Jul 2016 05:19:26 +0200 (CEST) Jan Engelhardt <jeng...@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
pgpJzgLESDe_h.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
