Is it's proper name DUB analog of CMake and other build tools from C world?

Am 22.09.2014 17:59, schrieb Poyeyo:
> On Monday, 22 September 2014 at 11:26:58 UTC, Sönke Ludwig wrote:
>> That would be a good thing - with more tests (and that is definitely
>> something that needs to be worked on, especially high level tests) it
>> will be more important to have a Windows tester, too, but so far
>> Travis/Linux has generally been sufficient, so there is no need for
>> hurry.
>
> Do you need a Windows tester or is that something automated?

No exactly, an automated tester. The majority of the time I'm working on Windows, so it's usually reasonably well tested there in general.

On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote:
> If you can think of any potentially important and especially backwards-incompatible changes/additions, please mention them (ideally as GitHub tickets), so that we can include them before the 1.0.0 release.

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.

Derelict [1] has solved this problem in a "clever" way, which allows leaving the least significant number for the binding [2][3]. Take for example the bindings for SDL [4]: Bindings for target version 2.0.1 are versioned as 1.1.0, 1.1.1, 1.1.2 and so on. Correspondingly, for target version 2.0.2, the binding versions are 1.2.0, 1.2.1 and so on. I guess, that for for target 2.1.0, the binging would be versioned 2.0.0, 2.0.1, and so on. I think that this is quite confusing. Is there a better way?

[1] https://github.com/DerelictOrg
[2] http://dblog.aldacron.net/derelict-help/using-derelict/
[3] http://dblog.aldacron.net/important-derelictsdl2-updates/
[4] http://code.dlang.org/packages/derelict-sdl2

This inclusion into the DMD install, is just that DMD comes with
the dub.exe and .dll's (and ofcourse the linux & mac equivalents)
in it's folders, correct?

On 22/09/14 23:04, tn 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.

The problem is locking the version of the Dub package to the same version of the library the bindings are for. In you're example I would do something like "1.2.3+1.2.3". If you need fix a bug in the bindings you increment as usual to "1.2.4+1.2.3". Anything after the plus sign is basically metadata that is ignore by Dub

-- 
/Jacob Carlborg

Am 23.09.2014 03:50, schrieb K.K.:
> This inclusion into the DMD install, is just that DMD comes with
> the dub.exe and .dll's (and ofcourse the linux & mac equivalents)
> in it's folders, correct?

Yes, that's it basically.

On Tuesday, 23 September 2014 at 06:22:27 UTC, Jacob Carlborg wrote:
> On 22/09/14 23:04, tn 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.
>
> The problem is locking the version of the Dub package to the same version of the library the bindings are for. In you're example I would do something like "1.2.3+1.2.3". If you need fix a bug in the bindings you increment as usual to "1.2.4+1.2.3". Anything after the plus sign is basically metadata that is ignore by Dub

In your suggestion, once version 1.2.4 of the target library is released, the first binding version targeting that would then be 1.2.4+1.2.4 or 1.2.5+1.2.4 or what?

And more importantly, how can a user of the binding then depend on the latest binding version of a specific target library version (for example the latest bindings for 1.2.3)?

Congratulations for this new release!

"dub" v0.9.22 deb package already available on "d-apt" <http://d-apt.sourceforge.net/>.

This new deb package includes "dub" auto-completion script.

Regards,
-- 
Jordi Sayol

Arch Linux package has been updated. Does not include auto-completion right now, will do a point release with it soon-ish

On 2014-09-23 10:08, tn wrote:

> In your suggestion, once version 1.2.4 of the target library is
> released, the first binding version targeting that would then be
> 1.2.4+1.2.4 or 1.2.5+1.2.4 or what?

If the previous binding version was 1.2.3+1.2.3 the next would be 1.2.4+1.2.4. Just increment as usual. It could also be that the target library doesn't follow Semver and if it contains an API breaking change it would be 2.0.0+1.2.4.

> And more importantly, how can a user of the binding then depend on the
> latest binding version of a specific target library version (for example
> the latest bindings for 1.2.3)?

Hmm, that's tricky. I don't have a good solution for that. It's easy to see if you look at all the versions. Just pick the highest version with the matching version after the plus.

-- 
/Jacob Carlborg