RejectedSoftware Forums

Sign up

SemVer limitations (need release postfix)

I'm maintaining Deimos bindings for FreeImage 1 and am currently
stuck while trying to tag a bugfix commit.
The problem is that I reused FreeImage's version numbers for the
bindings, but now I'm stuck with v3.16.0 and cannot increase the version
without deviating from the FreeImage version.
The X.Y.Z+build.tail is ignored for comparison.

I wonder what's the best option to deal with this.

  • use separate versioning for bindings (intransparent mapping between
    binding and library version)
  • always use prerelease versions(similar to RPM packages 2)
    v3.16.0-0.1+alpha
    v3.16.0-0.2+beta
    v3.16.0-1 #release
    v3.16.0-2 #followup release

Any other ideas?

http://fedoraproject.org/wiki/Packaging:NamingGuidelines#PreReleaseExampleAlsaLib

Re: SemVer limitations (need release postfix)

On Sun, 05 Oct 2014 21:42:05 +0200, Martin Nowak wrote:

I'm maintaining Deimos bindings for FreeImage [1][] and am currently
stuck while trying to tag a bugfix commit.
The problem is that I reused FreeImage's version numbers for the
bindings, but now I'm stuck with v3.16.0 and cannot increase the version
without deviating from the FreeImage version.
The X.Y.Z+build.tail is ignored for comparison.

I wonder what's the best option to deal with this.

  • use separate versioning for bindings (intransparent mapping between

binding and library version)

  • always use prerelease versions(similar to RPM packages [2][])
    v3.16.0-0.1+alpha
    v3.16.0-0.2+beta
    v3.16.0-1 #release
    v3.16.0-2 #followup release

Any other ideas?

[1]: https://github.com/D-Programming-Deimos/FreeImage/tags
[2]:
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#PreReleaseExampleAlsaLib

If I recall correctly, this was recently discussed somewhere, unfortunately I cannot find it now. I think the conclusion was that you should avoid tying the version of the bindings to the version of the library.

/Jacob Carlborg

Re: SemVer limitations (need release postfix)

On 10/06/2014 09:43 AM, Jacob Carlborg wrote:

If I recall correctly, this was recently discussed somewhere, unfortunately I cannot find it now. I think the conclusion was that you should avoid tying the version of the bindings to the version of the library.

Sure that would solve the problem, but the missing mapping is really a
pain. I tried the prerelease suffix [1][] on my latest binding, seems to
work.

http://code.dlang.org/packages/d-blosc