libdisplay-info 0.1.0

To allow compositors to start using libdisplay-info, it would be nice to ship 0.1.0. I don't think we want to commit to a stable API this early.

Milestone: %0.1.0

changed milestone to %0.1.0

mentioned in issue #24 (closed)

Do we want to block on anything here? Maybe some pending low-level bits?

Might be nice to have !116 (merged) ?

I have no objections, or needs in my mind that would need to be in the first release. Once there is one release, it's easy to cut more, right?

I agree with making it clear that the API and ABI are still unstable.

Indeed, numbers are cheap so we can make new releases as needed.

The main thing missing IMO is the README explaining the expectations wrt. release numbering and API/ABI stability promises.

Do we want to solve #13 before the first release?

Do we want to disable building a shared library or installing anything until we can promise a stable ABI?

Good points. Yes to solving #13 first and yes to disabling building a shared library from me.

Do we want to disable building a shared library or installing anything until we can promise a stable ABI?

What would be the goal here? Prevent distros from shipping it?

wlroots wouldn't be able to use the library that way.

Exactly. You do not want anyone shipping a shared library with an unstable ABI even accidentally.

Wouldn't wlroots use this as a (Meson sub-project) static library? That's what I plan on Weston doing, because libdisplay-info has unstable ABI still.

OTOH, if you do want to ship the shared library with unstable ABI, you need a plan for bumping the major version on every breaking release. We could do what libweston does with full parallel installability of even development files, or go with the more subtle libtool versioning bumping only soname and not the library and pkg-config names.

Which way do you want to go?

I checked the semver you proposed in !140 (merged). How do distributions handle the major version 0 breaking ABI all the time? Can they distribute that?

Can distributions distribute multiple incompatible major=0 versions of the library, installed simultaneously?

I think we have 3 options:

1. Do not ship a shared library
2. Bake the version into the name (e.g. libdisplay-info-0.2.so)
3. Choose another name and bump the major/SONAME (libdisplay-info-unstable.so.2)

Technically I think 2 and 3 are not sem-ver compliant. I would choose 1 if there isn't a good argument for another option.

We can still ship -devel packages in distributions without a shared library.

I don't see any of the options as non-compliant with sem-ver. File names and SONAMEs are orthogonal to the versioning scheme. The thing that matters is that SONAME changes when stable ABI breaks. Anything on top of that, like being able to install multiple incompatible versions simultaneously, is just extra convenience that might be really nice.

Should we care about distributions at all?

They tend to find their ways to ship stuff and make it work, no matter what we do, but OTOH it would be nice to play nice and make things easy for them.

FWIW, I'm not sure if I'll make libdisplay-info a hard dependency in Weston from the start. Maybe I need to keep it optional for a while. I could make it mandatory for building CM&HDR support. Then later make it a hard dependency for DRM-backend.

I'd be fine with any of Sebastian's three options. I would like to avoid the situation where ABI breaks but SONAME does not change, even if the ABI is not stable.

I don't have a strong opinion but would prefer disabling building the dynamic library. @emersion since you're the one who wants the dynamic library it's up to you to come up with a scheme.

wlroots wouldn't be able to use the library that way.

@emersion can you elaborate why not?

it would be nice to play nice and make things easy for [distributions].

One needs to be careful when trying to be nice to distros. It's very easy to misunderstand what makes it easy for distros and do exactly the opposite.

Distros are generally not okay with building compositors linked to static libraries. They prefer dynamic libraries. I've tried doing the static library/Meson subproject approach with libliftoff, and heard back from multiple distros complaining that they want dynamic linking, even if the library is unstable.

We've been shipping both libliftoff and wlroots as a shared library, with an unstable API and no way to install two versions in parallel. IIRC libseat as well had a few API changes. We still bump SONAME with each release, to make sure we don't dynamically link with an incompatible library by mistake. Also the version constraints for wlroots users look like version: ['>=0.15.0', '<0.16.0'].

Even when it's possible to install different versions in parallel, the distros I know of don't package the multiple versions in general. For instance Arch has only one version of Weston, and one version of llvm (Arch has shipped an outdated llvm 14 for a few months while waiting for all dependencies to support the llvm 15 API). I am not familiar with Fedora/Debian.

Some distros like Alpine and Void have occasionally shipped a separate package for a specific wlroots version with just the .so and nothing else in case one dependency lagged behind.

Distros are generally not okay with building compositors linked to static libraries. They prefer dynamic libraries.

Right, I actually knew that, but somehow failed to think of it.

I am not familiar with Fedora/Debian.

Debian routinely changes the package name for shared libraries when the SONAME changes, which allows parallel installation in principle. Fedora allows parallel installation at least in some cases such as LLVM.

I do know distros hate static libs.

If Mutter needs one version and kwin needs a different incompatible version of the library, does it mean that it is impossible to have GNOME and KDE installed at the same time? Do we want to avoid such a situation? How?

When what distros want and what developers need conflict it is usually better to just trust your own judgement.

DXVK (which also builds on Linux) is also shipping its own fork that has Windows support too...

If its a problem for distros then imo they should just have to bite the bullet in this period.

Doing things right now when we cannot guarantee ABI stability matters more than $DISTRO's weird policy we didn't sign up for.

Let's do the libliftoff thing then, since that's already proven with distros and breaking ABI, if it doesn't prevent installing two projects needing incompatible versions of it simultaneously.

Users just need to be careful with their version dependencies and remember to include the upper version limit.

Are there actual code changes needed or is libdisplay-info already doing everything that libliftoff does wrt. installing and versioning?

With !149 (merged), this thread is resolved.

Do we need anything else for the release? What does the release process look like? Should we document it?

As long as the ABI remains unstable, I think we're good. After the question of what to install is solved, one last check to make sure the installation looks good.

Documenting the release process is good, then more people could do it. @emersion has the experience, so maybe he can copy the needed bits from somewhere?

Release docs came with !149 (merged).

Looks like there is nothing left to prepare?

I checked the installation and SONAME, they looked good. Nothing listed in %0.1.0 milestone either.

0.1.0 released a while ago, and 0.1.1 too.

closed