It appears that libdvbv5 has undergone an (unnoticed by me till just now) version change. This raises a general question for creators of D bindings.

libdvbv5 has versions 1.12.x, 1.14.x, 1.16.x, etc, following the "odd is internal, even is released" minor version number strategy. It seems wrong somehow to follow that numbering for the D binding; the binding needs to have a separate evolution. However the binding has to allow the user to choose the major.minor number of the underlying library they have – though that should perhaps be done automatically using the pkg-config system.

Has anyone had previous experience of this situation and can give advice/direction so I don't have to build a solution from first principles?

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thursday, 10 January 2019 at 05:44:22 UTC, Russel Winder wrote:
> It appears that libdvbv5 has undergone an (unnoticed by me till just now) version change. This raises a general question for creators of D bindings.
>
> libdvbv5 has versions 1.12.x, 1.14.x, 1.16.x, etc, following the "odd is internal, even is released" minor version number strategy. It seems wrong somehow to follow that numbering for the D binding; the binding needs to have a separate evolution. However the binding has to allow the user to choose the major.minor number of the underlying library they have – though that should perhaps be done automatically using the pkg-config system.
>
> Has anyone had previous experience of this situation and can give advice/direction so I don't have to build a solution from first principles?

Use version conditions for the different library versions to set up compile-time versions you can static if on:

```
enum DVBVSupport {
    v112  = 112,
    v114  = 114,
    v116  = 116,
}

version(DVBV_114) {
    enum dvbvSupport = DVBVSupport.v114;
}
else version(DVBV_116) {
    enum dvbvSupport = DVBVSupport.v116;
}
else enum dvbvSupport = DVBVSupport.v114;

// Declarations supported in 1.12
...

static if(dvbvSupport >= DVBVSupport.v114) {
...
}

static if(dvbvSupport >= DVBVSupport.v116) {
...
}
```

This is how I handle it in the BindBC libraries, to which I'm porting all the active bindings from the DerelictOrg group (where I handled it with different git branches, which is a horribly confusing and inefficient way to go about it):

https://github.com/BindBC

The only drawback to it right now is that static if isn't supported inside enum declarations, so you'll wind up with multiple declarations of the enum, as I did with SDL_EventType here:

https://github.com/BindBC/bindbc-sdl/blob/master/source/bindbc/sdl/bind/sdlevents.d#L25

static if *is* supported in class & struct delcarations, though, and you can see it used in that same file in some of the event types, like SDL_MouseButtonEvent and SDL_MouseWheelEvent:

https://github.com/BindBC/bindbc-sdl/blob/master/source/bindbc/sdl/bind/sdlevents.d#L347

On Thursday, 10 January 2019 at 10:28:55 UTC, Mike Parker wrote:

> to set up compile-time versions

Compile-time *values*

> else enum dvbvSupport = DVBVSupport.v114;

This, of course, should be = DVBVSupport.v112

On 2019-01-10 06:44, Russel Winder wrote:
> It appears that libdvbv5 has undergone an (unnoticed by me till just now)
> version change. This raises a general question for creators of D bindings.
> 
> libdvbv5 has versions 1.12.x, 1.14.x, 1.16.x, etc, following the "odd is
> internal, even is released" minor version number strategy. It seems wrong
> somehow to follow that numbering for the D binding; the binding needs to have
> a separate evolution. However the binding has to allow the user to choose the
> major.minor number of the underlying library they have – though that should
> perhaps be done automatically using the pkg-config system.
> 
> Has anyone had previous experience of this situation and can give
> advice/direction so I don't have to build a solution from first principles?

If you only support one version of libdvbv5 for each version of the bindings, it will be much easier. If someone wants to use an older version of libdvbv5 than the bindings support they can use and older version of the bindings.

But as long as symbols aren't removed in later versions of libdvbv5 the newest versions of the bindings can be used. Even if a symbol is removed, it shouldn't be a problem until it's used.

As for setting the version on the bindings you can do something like: 1.0.0+1.16.0. Where "1.0.0" is the version of the bindings and "1.16.0" is the version of libdvbv5 the bindings support. Anything after "+" in semantic versioning is metadata and doesn't have any affect.

-- 
/Jacob Carlborg