Re: [ANNOUNCE] libgpiod v1.6 released

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

On Fri, Oct 2, 2020 at 10:25 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> On Thu, Oct 1, 2020 at 4:56 PM Andy Shevchenko
> <andy.shevchenko@xxxxxxxxx> wrote:

> > > 1. Switch the major version of libgpiod API to 2 and start working on
> > > the new API (preferably starting out by simply porting the current
> > > library to v2 uAPI).
> > > 2. Indefinitely support v1.6.x branch with bug fixes.
> > > 3. Consider v1.4.x as an LTS supported for as long as yocto uses v5.4
> > > kernel as their LTS (this is because v1.4 is the last version to not
> > > require v5.5 kernel headers to build).
> > > 4. (maybe) Create a compatibility layer between v1.x and v2.x once
> > > v2.0 is out that will ease the switch to the new release.
> >
> > I'm wondering if you are planning to develop v2.x with possibility to
> > coexist with v1 on the same machine (like gtk2 / gtk3 and other
> > examples).
> >
>
> Personally I would prefer to avoid doing this. This isn't a very big
> library so unlike gstreamer or gtk I think it won't take much to
> switch to v2.0. If anything - I prefer a compatibility layer included
> in the package where - if an option is passed to configure - the old
> header would be installed alongside the v2.0 .so file + another .so
> for translating the calls.
>
> If you see a very good reason to make them both live together - let me know.

Aspects that come to my mind, that needs to be taken into account are
the following:
 - would ABI be kept on a library level (will binary built against v1
be capable to run on v2)?
 - would API be kept compatible (seems so according to Kent's patch)?

Main point that users that have compiled something for older kernel to
work should be able to run this on newer distribution environments
(like one, that would have only v2 of the library).

-- 
With Best Regards,
Andy Shevchenko