DUB qustion - what is the right way to package a binding to a library with more than one major version?

[Dejan Lekic]

To give you a context - I am done with my binding to the [HDF5 
library](https://www.hdfgroup.org/solutions/hdf5/). My binding is 
based on 1.14.4 version of the library that I have locally on my 
Fedora workstation. Two weeks ago they have released version 
2.0.0 of the library and now I am torn between two approaches to 
packaging versions 1 and 2 of the libhdf5.

### Approach 1

Have two DUB packages - `ddn-lib-hdf5v1` that has tags refering 
to branches forked from the `v1` branch, and `dub-lib-hdf5v2` 
that points to the `main` branch, until HDF5 group releases 
v3.0.0, in which case I will fork `main` and create `v2`. 
`v2.x.y` tags would all be referring to commits in this branch.

Main reason why I am inclining to this approach (with two 
different DUB packages) is that it is giving me ability to 
version my own binding. For an example I will have ddn-lib-hdf5v1 
v14.4.D, where `D` is version of the binding. Some distributions 
are actually using this approach nowadays because it makes 
everything as close to what SemVer as specified on semver.org 
proposes.

PS. this is a rare case when `v` had to be added to the package 
name to avoid confusion (imagine `ddn-lib-hdf51` as name).

### Approach 2

This approach is simple. Have a single `ddn-lib-hdf5` dub package 
that closely match what the upstream version is. So, I will have 
`ddn-lib-hdf5` 1.14.4 dub package. Problem with this is that 
versions of the binding would have to be `post-releases` as 
specified by SemVer (https://semver.org), so if I make a change 
to my binding, it would become something like 1.14.4+D (or as 
Hipreme suggested on Discord +ddnM, where M is version of the 
binding)

Is there any other alternative that could still be semver 
"compliant"? If so, please let me know.