On Mon, Sep 22, 2014 at 21:04:24 +0000, tn via Digitalmars-d-announce wrote:
> What is the recommended way of versioning bindings? If the binding of the target library 1.2.3 is versioned as 1.2.3 and a bug is fixed in the binding (no change in the target library), how should the new version of the binding for target version 1.2.3 be versioned? Using 1.2.4 is not an option because it potentially collides with the binding for the next version of the target.

What about 1.2.3.x? How does dub handle letters in version numbers? Maybe "1.2.3.0w" would be viable ('w' for 'wrap').

--Ben

On 25/09/14 21:38, Ben Boeckel via Digitalmars-d-announce wrote:

> What about 1.2.3.x? How does dub handle letters in version numbers?
> Maybe "1.2.3.0w" would be viable ('w' for 'wrap').

I don't think that's allowed. Dub's following this versioning scheme: http://semver.org/

-- 
/Jacob Carlborg

On Thursday, 25 September 2014 at 19:38:47 UTC, Ben Boeckel via Digitalmars-d-announce wrote:
>
> What about 1.2.3.x? How does dub handle letters in version numbers?
> Maybe "1.2.3.0w" would be viable ('w' for 'wrap').

1.2.3.x is an invalid version number. Only 3 group numbers are allowed [1]. Though you could use prerelease and/or build suffixes (1.2.3-0w / 1.2.3+0w).


[1] - www.semver.org

On Friday, 26 September 2014 at 06:29:21 UTC, Dragos Carp wrote:
> Though you could use prerelease and/or build suffixes (1.2.3-0w / 1.2.3+0w).

These are very close to what I would like to see.

Though, if I understand correctly, build suffix wouldn't work, as for example 1.2.3+0w and 1.2.3+1w would be treated as equal: "Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence." (semver.org)

I guess that prerelease suffixes would do the trick. The only problem is conceptual: "A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version." (semver.org)

On Friday, 26 September 2014 at 08:37:12 UTC, tn wrote:
> On Friday, 26 September 2014 at 06:29:21 UTC, Dragos Carp wrote:
>> Though you could use prerelease and/or build suffixes (1.2.3-0w / 1.2.3+0w).
>
> These are very close to what I would like to see.
>
> Though, if I understand correctly, build suffix wouldn't work, as for example 1.2.3+0w and 1.2.3+1w would be treated as equal: "Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence." (semver.org)
>
> I guess that prerelease suffixes would do the trick. The only problem is conceptual: "A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version." (semver.org)

In semver library [1], the differences in build suffixes are a) "right" ordered (defined sort order) and not equal, and b) considered compatible.

a) SemVer("1.2.3+w.9") < SemVer("1.2.3+w.10")
   SemVer("1.2.3+w.9") != SemVer("1.2.3+w.10")

b) SemVer("1.2.3+w.9").satisfies(SemVerRange("1.2.3"))
   SemVer("1.2.3+w.10").satisfies(SemVerRange("1.2.3"))
   SemVer("1.2.3+w.9").differAt(SemVer("1.0.0+w.10")) == VersionPart.BUILD


[1] http://code.dlang.org/packages/semver

On Fri, Sep 26, 2014 at 06:29:19 +0000, Dragos Carp via Digitalmars-d-announce wrote:
> 1.2.3.x is an invalid version number. Only 3 group numbers are allowed [1]. Though you could use prerelease and/or build suffixes (1.2.3-0w / 1.2.3+0w).

How would you version a library which wraps another with 4 version components? Enforced semver to the limit that only 3 components are supported seems a little heavy-handed to me.

--Ben

Am 02.10.2014 14:27, schrieb Ben Boeckel via Digitalmars-d-announce:
> On Fri, Sep 26, 2014 at 06:29:19 +0000, Dragos Carp via Digitalmars-d-announce wrote:
>> 1.2.3.x is an invalid version number. Only 3 group numbers are
>> allowed [1]. Though you could use prerelease and/or build
>> suffixes (1.2.3-0w / 1.2.3+0w).
>
> How would you version a library which wraps another with 4 version
> components? Enforced semver to the limit that only 3 components are
> supported seems a little heavy-handed to me.
>
> --Ben
>

The idea is to have an interoperable standard - modifying it in any way would break that, so that we could as well completely invent our own standard.

The way I see it is that the binding should be considered as individually versioned. It should usually start at 1.0.0 (maybe X.0.0, where X is the major version of the wrapped library, if that makes sense for the original version scheme) and be incremented purely according to SemVer. The version of the wrapped library can be documented as build metadata, but that's it.

To me a big argument against supporting something non-standard, such as a fourth version digit is that it facilitates blindly adopting a libraries original version scheme, even if that may work in a completely different way w.r.t. major, minor and patch versions.

But the idea of SemVer is that you can safely specify a version range such as 1.2.x and be sure to only get bugfixes, or 1.x.x and only get backwards compatible changes. Many other schemes don't have such guarantees, so directly translating them would be the a step to chaos.

Thanks for your works,

One question, what about makefile support ?

Regards

Am 06.10.2014 13:36, schrieb bioinfornatics:
> Thanks for your works,
>
> One question, what about makefile support ?
>
> Regards

It's still in need for a volunteer. The implementation itself should be pretty straightforward (by inheriting from the ProjectGenerator class), but I currently have too much higher priority stuff on my table to get that done (plus generally severely limited time due to an accumulation of work and non-work related things).

On 10/06/2014 02:15 PM, Sönke Ludwig wrote:
> Am 06.10.2014 13:36, schrieb bioinfornatics:
>> Thanks for your works,
>>
>> One question, what about makefile support ?
>>
>> Regards
>
> It's still in need for a volunteer. The implementation itself should be
> pretty straightforward (by inheriting from the ProjectGenerator class),
> but I currently have too much higher priority stuff on my table to get
> that done (plus generally severely limited time due to an accumulation
> of work and non-work related things).

I don't suppose there's documentation on the ProjectGenerator class? I was (briefly) looking into subclassing that for a "compiler cmdline args" output that I think would be helpful, but based on a (again, rather brief) glance at and its subclasses I had some trouble grokking how it worked. I'll have to take a look again though.