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.
