eudev "forward compatibility" expectations

As I understand it, one intended use case of libudev-zero is to run programs compiled with udev without recompiling. However, it seems to also be possible to compile programs with libudev-zero and run with udev, or at least that is implied by

libudev-zero/udev.h

Line 131 in bf23c9e

// this is "libudev-zero" extension. do not use if portability is concern

I am considering proposing the replacement of eudev with libudev-zero, at least as the default option, in Alpine Linux and possibly other (mostly musl-based) distros. For this, it would be easier if this support can be expected to continue in the future? I understand that no definitive guarantees can be made, since the upstream udev API may change, but a statement of "yes, this case is intended to work and I currently hope to keep it that way in the future" would be greatly appreciated.

Thanks!

use case of libudev-zero is to run programs compiled with udev without recompiling

Only if program dynamically linked.

I am considering proposing the replacement of eudev with libudev-zero

Keep in mind that libudev-zero isn't a full replacement. Some programs may use functions that are not yet implemented. Other programs may rely on eudev/systemd-udev specific output(see #26).

Despite libudev-zero issues, KISS Linux/Iglunix/OpenWrt successfully replaced eudev with libudev-zero.

For this, it would be easier if this support can be expected to continue in the future?

I have a grand plan to write cross-platform library for interacting with device manager. The new library will fix long-standing udev design flaws and portability issues. Don't worry, I'll continue maintaining libudev-zero until it become obsolete(or I die X_X).

use case of libudev-zero is to run programs compiled with udev without recompiling

Only if program dynamically linked.

yes, of course.

I am considering proposing the replacement of eudev with libudev-zero

Keep in mind that libudev-zero isn't a full replacement. Some programs may use functions that are not yet implemented. Other programs may rely on eudev/systemd-udev specific output(see #26).

right.

I have a grand plan to write cross-platform library for interacting with device manager. The new library will fix long-standing udev design flaws and portability issues. Don't worry, I'll continue maintaining libudev-zero until it become obsolete(or I die X_X).

sounds good, i look forward to see it :)