ErupteD [0] is deprecated (one of its major modules). The project content is supposed to be replaced completely. Current state was copied into ErupteD-V1 [1] (without deprecation message), neither ErupteD nor ErupteD-V1 will be further developed.
The breaking changes and Vulkan 1.1 are implemented in ErupteD-V2 [2]. At some future point ErupteD will be destroyed and recreated with all releases of ErupteD-V2 [3].

Two issues bugged me with the previous design of the binding:
1. versions are not only disconnected from, but also far beyond Vulkan
2. too many dub dependencies - if on windows, than platform foreign ones

1. this is the reason for the involved transition, ErupteD needs to get rid of all releases / version tags to restart with a clean slate.
I also extracted the python generator script into its own non-dub project, V-Erupt [5]. It was kind of wired to mix two different purposes into one project version scheme.

2. the new approach does not require dependencies at all (other than phobos / druntime). Platform dependent extensions are implemented in form of a parameterizable mixin template. User is supposed to mix them into his project and take care of the dependencies himself [4]. Platform windows is pre-instantiated, as it relies only on druntime. With this approach dub cache stays clean from foreign platform dependencies and silences version mismatch noise.
While at it, I also removed the DerelictUtil dependency and added simple entrypoint loading mechanics. ErupteD-V2 is now fully nothrow @nogc and should be -betterC compatible (not tested yet). Moreover, no requirement for dub configurations any more.

[0] : https://github.com/ParticlePeter/ErupteD
[1] : https://github.com/ParticlePeter/ErupteD-V1
[2] : https://github.com/ParticlePeter/ErupteD-V2
[3] : https://github.com/ParticlePeter/ErupteD-V2#erupted-deprecation-and-upgrade-process
[4] : https://github.com/ParticlePeter/ErupteD-V2#platform-extensions
[5] : https://github.com/ParticlePeter/V-Erupt

On Sunday, 25 March 2018 at 22:23:06 UTC, Peter Particle wrote:
> ErupteD [0] is deprecated (one of its major modules). The project content is supposed to be replaced completely. Current state was copied into ErupteD-V1 [1] (without deprecation message), neither ErupteD nor ErupteD-V1 will be further developed.
> The breaking changes and Vulkan 1.1 are implemented in ErupteD-V2 [2]. At some future point ErupteD will be destroyed and recreated with all releases of ErupteD-V2 [3].
>
> Two issues bugged me with the previous design of the binding:
> 1. versions are not only disconnected from, but also far beyond Vulkan
> 2. too many dub dependencies - if on windows, than platform foreign ones
>
> 1. this is the reason for the involved transition, ErupteD needs to get rid of all releases / version tags to restart with a clean slate.
> I also extracted the python generator script into its own non-dub project, V-Erupt [5]. It was kind of wired to mix two different purposes into one project version scheme.
>
> 2. the new approach does not require dependencies at all (other than phobos / druntime). Platform dependent extensions are implemented in form of a parameterizable mixin template. User is supposed to mix them into his project and take care of the dependencies himself [4]. Platform windows is pre-instantiated, as it relies only on druntime. With this approach dub cache stays clean from foreign platform dependencies and silences version mismatch noise.
> While at it, I also removed the DerelictUtil dependency and added simple entrypoint loading mechanics. ErupteD-V2 is now fully nothrow @nogc and should be -betterC compatible (not tested yet). Moreover, no requirement for dub configurations any more.
>
> [0] : https://github.com/ParticlePeter/ErupteD
> [1] : https://github.com/ParticlePeter/ErupteD-V1
> [2] : https://github.com/ParticlePeter/ErupteD-V2
> [3] : https://github.com/ParticlePeter/ErupteD-V2#erupted-deprecation-and-upgrade-process
> [4] : https://github.com/ParticlePeter/ErupteD-V2#platform-extensions
> [5] : https://github.com/ParticlePeter/V-Erupt

1. This breaks semver. You shouldn't just use Vulkan's versions. If you release 1.0.69 which contains bindings to Vulkan 1.0.69 and there is a bug in the binding which you want to fix, you have to increase PATCH number which results in 1.0.70 which (obviously) is not a binding to Vulkan 1.0.70.

Even though you can use PRE-RELEASE part of semver to show users that this is a bugfix release (ie. 1.0.69-bugfix.1) this shouldn't be used because it breaks semver *again* and dub (which follows semver) isn't going to tolerate that.

This is a *bad* idea and you shouldn't do that.

Just increase MAJOR version and start from there:

2.0.0 - Changing how binding works, Vulkan v1.0.69
2.1.0 - Vulkan 1.0.70

...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos.

Also, if you'll stick to your *bad-in-every-way* plan, you *can't* publish erupted-v2 as erupted package on dub registry. You'd have to remove it from registry first, which will break every single package that depends on it.

2. Great! I ended up adding erupted as a git submodule just so I can remove all of the unnecessary dependencies (erupted uses pretty old derelict-util which makes it impossible to use both erupted and last version of derelict-glfw).

Erupted-V2 doesn't work for me - when compiling on Linux it fails on some Windows-specific code. I'll open an issue as soon as I get home.

On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote:
> This is a *bad* idea and you shouldn't do that.
>
> Just increase MAJOR version and start from there:
>
> 2.0.0 - Changing how binding works, Vulkan v1.0.69
> 2.1.0 - Vulkan 1.0.70
>
> ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos.

Also note that SemVer allows to attach meta data:

2.0.0+1.0.69

> Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence.

https://semver.org/#spec-item-10

On Monday, 26 March 2018 at 07:51:31 UTC, Seb wrote:
> On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote:
>> This is a *bad* idea and you shouldn't do that.
>>
>> Just increase MAJOR version and start from there:
>>
>> 2.0.0 - Changing how binding works, Vulkan v1.0.69
>> 2.1.0 - Vulkan 1.0.70
>>
>> ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos.
>
> Also note that SemVer allows to attach meta data:
>
> 2.0.0+1.0.69

That'll work too, but I'm not sure how dub handles it. Anyway, even a little note in release description "Vulkan API vX.X.X" should be enough.

On Monday, 26 March 2018 at 09:04:20 UTC, Anton Fediushin wrote:
> On Monday, 26 March 2018 at 07:51:31 UTC, Seb wrote:
>> On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote:
>>> This is a *bad* idea and you shouldn't do that.
>>>
>>> Just increase MAJOR version and start from there:
>>>
>>> 2.0.0 - Changing how binding works, Vulkan v1.0.69
>>> 2.1.0 - Vulkan 1.0.70
>>>
>>> ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos.
>>
>> Also note that SemVer allows to attach meta data:
>>
>> 2.0.0+1.0.69
>
> That'll work too, but I'm not sure how dub handles it. Anyway, even a little note in release description "Vulkan API vX.X.X" should be enough.

It will work fine with dub (it just ignores the meta data).
For example, if you do a `dub add-local`, your package version is "+ annotated" with the git commit sha.

First of all, don't worry, don't panic, we will figure it out, together ;-). Everything will be alright in the end, and if not, its not the end.

On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote:
> 1. This breaks semver. You shouldn't just use Vulkan's versions. If you release 1.0.69 which contains bindings to Vulkan 1.0.69 and there is a bug in the binding which you want to fix, you have to increase PATCH number which results in 1.0.70 which (obviously) is not a binding to Vulkan 1.0.70.

The bug then is not in ErupteD but in its generator. It needs to be fixed there.
The plan was to then move the sem vers to the bug fix release. Never done that, wanted to try it. Buuut, got inspired by a great idea 3 min ago (please read on).

> Even though you can use PRE-RELEASE part of semver to show users that this is a bugfix release (ie. 1.0.69-bugfix.1) this shouldn't be used because it breaks semver *again* and dub (which follows semver) isn't going to tolerate that.

Great idea! Have not considered it. So the Bug fix for version 1.1.70 could be 1.1.71-bugfix.1. How does it screw up dub semver?

> This is a *bad* idea and you shouldn't do that.

Why is it a bad idea, could you elaborate?

> Just increase MAJOR version and start from there:
>
> 2.0.0 - Changing how binding works, Vulkan v1.0.69
> 2.1.0 - Vulkan 1.0.70
>
> ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos.

Thought about that, but there is one issue which I mentioned in the announcement. I experience it as a bad idea to have the generator part of the binding. Both of them have different purpose and should have different version numbers. Meta data is nice approach as in GenVer+VulkanVer, but unfortunately dub upgrade is not triggered if Only vulkanVer increments. Hm...

> Also, if you'll stick to your *bad-in-every-way* plan, you *can't* publish erupted-v2 as erupted package on dub registry. You'd have to remove it from registry first, which will break every single package that depends on it.

Thanks for your nice words all over the place, sun is rising in my hart :-). Well, yeah, I didn't. ErupteD-V2 is published as erupted_v2, and Erupted-V1 as erupted_v1.

Hey, I have another awesome idea, you are an the safe side, you just change your dependency to erupted_v1. I hope this is not too much of effort on your side? Sorry for inconvenience. Ah, but wait! Fear not, I read ahead and have a solution for your way of using erupted, just read on.

> 2. Great! I ended up adding erupted as a git submodule just so

Wouldn't it be possible for you to switch your submodule to ErupteD-V1 then?
I mean, that's the reason for repo "mess" and gradual transition.

> I can remove all of the unnecessary dependencies (erupted uses pretty old derelict-util which makes it impossible to use both erupted and last version of derelict-glfw).

Ah, but that was one of the two reason for the breaking change. Btw. I am/was using diferent versioned derelict-utils and have no problems other than being informed that xcb-d (on windows!) does not use it. What is the "impossible" part you have to face?

> Erupted-V2 doesn't work for me - when compiling on Linux it fails on some Windows-specific code. I'll open an issue as soon as I get home.

I am really sorry for that, I have an idea what might be wrong. Please, if you don't min, post an issue with the error. I hope that in this alpha stage of ErupteD-V2, where some poo poo was expected to hit the fan, it would be ok to move the semvers. Actually, if you use ErupteD as a submodule, why do care about semvers at all?

Please be patient we have not reached the end of the transition period, where everything will be all right again [0] at the end, I promise!

[0] http://make-everything-ok.com/

On Monday, 26 March 2018 at 09:20:13 UTC, ParticlePeter wrote:
> First of all, don't worry, don't panic, we will figure it out, together ;-). Everything will be alright in the end, and if not, its not the end.
>
> On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote:
>> 1. This breaks semver. You shouldn't just use Vulkan's versions. If you release 1.0.69 which contains bindings to Vulkan 1.0.69 and there is a bug in the binding which you want to fix, you have to increase PATCH number which results in 1.0.70 which (obviously) is not a binding to Vulkan 1.0.70.
>
> The bug then is not in ErupteD but in its generator. It needs to be fixed there.
> The plan was to then move the sem vers to the bug fix release. Never done that, wanted to try it. Buuut, got inspired by a great idea 3 min ago (please read on).

After generator is fixed it'll produce new binding which should be marked as a new release.

>> Even though you can use PRE-RELEASE part of semver to show users that this is a bugfix release (ie. 1.0.69-bugfix.1) this shouldn't be used because it breaks semver *again* and dub (which follows semver) isn't going to tolerate that.
>
> Great idea! Have not considered it. So the Bug fix for version 1.1.70 could be 1.1.71-bugfix.1. How does it screw up dub semver?

Dub isn't going to use pre-release version unless it is specified in user's dub.json. So, if user already has erupted 1.1.70 as a dependency, he will *never* receive 1.1.70-bugfix.1 unless he updates his dub.json. Basic 'dub upgrade' won't work in this case.

>> This is a *bad* idea and you shouldn't do that.
>
> Why is it a bad idea, could you elaborate?

Because it doesn't follow semver meaning that dub won't work correctly.

>> Just increase MAJOR version and start from there:
>>
>> 2.0.0 - Changing how binding works, Vulkan v1.0.69
>> 2.1.0 - Vulkan 1.0.70
>>
>> ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos.
>
> Thought about that, but there is one issue which I mentioned in the announcement. I experience it as a bad idea to have the generator part of the binding. Both of them have different purpose and should have different version numbers. Meta data is nice approach as in GenVer+VulkanVer, but unfortunately dub upgrade is not triggered if Only vulkanVer increments. Hm...

Indeed, metadata change isn't going to trigger an update neither does pre-release.

My solution:
1. Add generator as a git submodule (generator could be versioned)
2. Start versioning from 2.0.0 increasing MINOR when new Vulkan version is supported and increasing PATCH when bug fixes happen. Metadata can be added too.

This way users are going to always get latest version possible.

It'll look like this:

2.0.0+1.0.69
2.0.1+1.0.69 - first bugfix
2.1.0+1.0.70 - new vulkan version
2.1.1+1.0.70 - first bugfix

...And so on.

>> Also, if you'll stick to your *bad-in-every-way* plan, you *can't* publish erupted-v2 as erupted package on dub registry. You'd have to remove it from registry first, which will break every single package that depends on it.
>
> Thanks for your nice words all over the place, sun is rising in my hart :-). Well, yeah, I didn't. ErupteD-V2 is published as erupted_v2, and Erupted-V1 as erupted_v1.
>
> Hey, I have another awesome idea, you are an the safe side, you just change your dependency to erupted_v1. I hope this is not too much of effort on your side? Sorry for inconvenience. Ah, but wait! Fear not, I read ahead and have a solution for your way of using erupted, just read on.

I already use erupted-v1. Deprecation messages annoy me.

>> 2. Great! I ended up adding erupted as a git submodule just so
>
> Wouldn't it be possible for you to switch your submodule to ErupteD-V1 then?
> I mean, that's the reason for repo "mess" and gradual transition.
>
>> I can remove all of the unnecessary dependencies (erupted uses pretty old derelict-util which makes it impossible to use both erupted and last version of derelict-glfw).
>
> Ah, but that was one of the two reason for the breaking change. Btw. I am/was using diferent versioned derelict-utils and have no problems other than being informed that xcb-d (on windows!) does not use it. What is the "impossible" part you have to face?

Erupted uses derelict-util 2.something.something and derelict-glfw uses 3.0.0-beta. Because of that dub warns about version mismatch every single time I build my program.

Well, that's not impossible to use, but pretty annoying.

>> Erupted-V2 doesn't work for me - when compiling on Linux it fails on some Windows-specific code. I'll open an issue as soon as I get home.
>
> I am really sorry for that, I have an idea what might be wrong. Please, if you don't min, post an issue with the error. I hope that in this alpha stage of ErupteD-V2, where some poo poo was expected to hit the fan, it would be ok to move the semvers. Actually, if you use ErupteD as a submodule, why do care about semvers at all?

Because dub can notify about new version. That's why it exists in the first place

>
> Please be patient we have not reached the end of the transition period, where everything will be all right again [0] at the end, I promise!
>
> [0] http://make-everything-ok.com/

On Monday, 26 March 2018 at 09:50:16 UTC, Anton Fediushin wrote:
> On Monday, 26 March 2018 at 09:20:13 UTC, ParticlePeter wrote:
>> First of all, don't worry, don't panic, we will figure it out, together ;-). Everything will be alright in the end, and if not, its not the end.
[snip]
>> The bug then is not in ErupteD but in its generator. It needs to be fixed there.
>> The plan was to then move the sem vers to the bug fix release. Never done that, wanted to try it. Buuut, got inspired by a great idea 3 min ago (please read on).
>
> After generator is fixed it'll produce new binding which should be marked as a new release.

I strongly believe that the generator can be made fail safe, so that the produced binding is error free. I will elaborate a little more about the greater plan at the bottom, I just didn't think that anyone is interested in it.

[snip]

>> Great idea! Have not considered it. So the Bug fix for version 1.1.70 could be 1.1.71-bugfix.1. How does it screw up dub semver?
>
> Dub isn't going to use pre-release version unless it is specified in user's dub.json. So, if user already has erupted 1.1.70 as a dependency, he will *never* receive 1.1.70-bugfix.1 unless he updates his dub.json. Basic 'dub upgrade' won't work in this case.

Here I was hoping for a little more attentive reading, the bugfix (if any bugs happen in the end) for v1.1.70 would be v1.1.71 (as in "point seven ONE") -bugfix.1. I would hope for community colaboration to always use prerelease. Not sure if this is the best idea, as it cannot be specified in dub dependency afaics, but only on dub upgrade. That might actually be expecting to much from users. I'll think about it.

>>> This is a *bad* idea and you shouldn't do that.
>>
>> Why is it a bad idea, could you elaborate?
>
> Because it doesn't follow semver meaning that dub won't work correctly.

Dah, yes it does! As explained above at least :-)

[snip]
>
> Indeed, metadata change isn't going to trigger an update neither does pre-release.
>
> My solution:
> 1. Add generator as a git submodule (generator could be versioned)
> 2. Start versioning from 2.0.0 increasing MINOR when new Vulkan version is supported and increasing PATCH when bug fixes happen. Metadata can be added too.
>
> This way users are going to always get latest version possible.
>
> It'll look like this:
>
> 2.0.0+1.0.69
> 2.0.1+1.0.69 - first bugfix
> 2.1.0+1.0.70 - new vulkan version
> 2.1.1+1.0.70 - first bugfix
>
> ...And so on.

Hm, don't like it. The generator part is not changing when releasing a new vulkan version, but its version has to be incremented to triger an update. The generator itself should be incremented only if he produces buggy code. Actually this is part of my 1. explenation.

>>> Also, if you'll stick to your *bad-in-every-way* plan, you *can't* publish erupted-v2 as erupted package on dub registry. You'd have to remove it from registry first, which will break every single package that depends on it.
>>
>> Thanks for your nice words all over the place, sun is rising in my hart :-). Well, yeah, I didn't. ErupteD-V2 is published as erupted_v2, and Erupted-V1 as erupted_v1.
>>
>> Hey, I have another awesome idea, you are an the safe side, you just change your dependency to erupted_v1. I hope this is not too much of effort on your side? Sorry for inconvenience. Ah, but wait! Fear not, I read ahead and have a solution for your way of using erupted, just read on.
>
> I already use erupted-v1. Deprecation messages annoy me.

Dah again, no it cannot. Could it be that you are talking about DEPRECATED ErupteD? Please compare [0] and [1], and their project names.

[snip]
>> Ah, but that was one of the two reason for the breaking change. Btw. I am/was using diferent versioned derelict-utils and have no problems other than being informed that xcb-d (on windows!) does not use it. What is the "impossible" part you have to face?
>
> Erupted uses derelict-util 2.something.something and derelict-glfw uses 3.0.0-beta. Because of that dub warns about version mismatch every single time I build my program.
>
> Well, that's not impossible to use, but pretty annoying.

Yeah sounds different than impossible, doesn't it? But as said, that is 2. reason of my breaking change.

>>> Erupted-V2 doesn't work for me - when compiling on Linux it fails on some Windows-specific code. I'll open an issue as soon as I get home.
>>
>> I am really sorry for that, I have an idea what might be wrong. Please, if you don't min, post an issue with the error. I hope that in this alpha stage of ErupteD-V2, where some poo poo was expected to hit the fan, it would be ok to move the semvers. Actually, if you use ErupteD as a submodule, why do care about semvers at all?
>
> Because dub can notify about new version. That's why it exists in the first place

Sorry, here I cannot follow any more, so why are you using it then as a submodule again?


The GREATER Plan - as promised
------------------------------

I want to evolve and learn more about techniques which I have never touched before. This is already great I would think. But fun aside, I would like to look into full automation.

1.) get informed about vulkan-docs updates, trigger automated build process with V-Erupt. Is this possible? Don't know, want to find out.

2.) setup auto testing for ErupteD-V2. If fail, get informed. Else apply version tag, the same as vulkan-docs. Is this possible? Don't know, want to find out.

This sounds pretty fail safe to me, unless I screw up the test system.


The not so great plan - as compromise
-------------------------------------

Until I have that system running, I would also upgrade ErupteD-V1 to the latest Vulkan versions, possibly using your suggestion. Have to think about my prefered way, but attach the actual vulkan version as meta data.

@Seb, not ignoring you, but I felt I replied to your comment in my previous message as well. Sadly change of meta data is not triggering an update.

[0] https://github.com/ParticlePeter/ErupteD/blob/master/source/erupted/types.d
[1] https://github.com/ParticlePeter/ErupteD-V1/blob/master/source/erupted/types.d

On Monday, 26 March 2018 at 11:13:03 UTC, ParticlePeter wrote:
> I strongly believe that the generator can be made fail safe, so that the produced binding is error free. I will elaborate a little more about the greater plan at the bottom, I just didn't think that anyone is interested in it.

Well, I am interested in it - Vulkan is cool and so is D.

> Here I was hoping for a little more attentive reading, the bugfix (if any bugs happen in the end) for v1.1.70 would be v1.1.71 (as in "point seven ONE") -bugfix.1. I would hope for community colaboration to always use prerelease. Not sure if this is the best idea, as it cannot be specified in dub dependency afaics, but only on dub upgrade. That might actually be expecting to much from users. I'll think about it.

But then 1.1.71 without `-bugfix.1` will be a binding to vulkan v1.1.71? That doesn't make any sense.

> Dah again, no it cannot. Could it be that you are talking about DEPRECATED ErupteD? Please compare [0] and [1], and their project names.

I'm talking about erupted-v1.

>>>> Erupted-V2 doesn't work for me - when compiling on Linux it fails on some Windows-specific code. I'll open an issue as soon as I get home.
>>>
>>> I am really sorry for that, I have an idea what might be wrong. Please, if you don't min, post an issue with the error. I hope that in this alpha stage of ErupteD-V2, where some poo poo was expected to hit the fan, it would be ok to move the semvers. Actually, if you use ErupteD as a submodule, why do care about semvers at all?
>>
>> Because dub can notify about new version. That's why it exists in the first place
>
> Sorry, here I cannot follow any more, so why are you using it then as a submodule again?

Erupted_v1 has a configuration which uses old derelict-util. Even though I use derelict-glfw to load vulkan, dub downloads both old derelict-util and the new one used by derelict-glfw. This results in warnings because versions mismatch (erupted wants old one while derelict-glfw uses newest).

I opened an issue about erupted-v2 on linux as well: https://github.com/ParticlePeter/Erupted-V2/issues/1

> The GREATER Plan - as promised
> ------------------------------
>
> I want to evolve and learn more about techniques which I have never touched before. This is already great I would think. But fun aside, I would like to look into full automation.
>
> 1.) get informed about vulkan-docs updates, trigger automated build process with V-Erupt. Is this possible? Don't know, want to find out.

I think it is possible.

> 2.) setup auto testing for ErupteD-V2. If fail, get informed. Else apply version tag, the same as vulkan-docs. Is this possible? Don't know, want to find out.

It is possible but tests are required. More tests - better.

On Monday, 26 March 2018 at 12:22:25 UTC, Anton Fediushin wrote:
> On Monday, 26 March 2018 at 11:13:03 UTC, ParticlePeter wrote:

[snip]
>> Here I was hoping for a little more attentive reading, the bugfix (if any bugs happen in the end) for v1.1.70 would be v1.1.71 (as in "point seven ONE") -bugfix.1. I would hope for community colaboration to always use prerelease. Not sure if this is the best idea, as it cannot be specified in dub dependency afaics, but only on dub upgrade. That might actually be expecting to much from users. I'll think about it.
>
> But then 1.1.71 without `-bugfix.1` will be a binding to vulkan v1.1.71? That doesn't make any sense.

Actually, for me it does, afaik we can put whatever into the pre-release names, so this would work for me: v1.1.71-bugfix.1.1.70.1
It informs me that v1.1.71 is on its way but we are fixing 1.1.70 bugs before that.

>> Dah again, no it cannot. Could it be that you are talking about DEPRECATED ErupteD? Please compare [0] and [1], and their project names.
>
> I'm talking about erupted-v1.

I think you have old ErupteD modules in your ErupteD-V1 source directory. Please try to remove them and re-fetch E-V1.

[snip]
>>>> move the semvers. Actually, if you use ErupteD as a submodule, why do care about semvers at all?
>>>
>>> Because dub can notify about new version. That's why it exists in the first place
>>
>> Sorry, here I cannot follow any more, so why are you using it then as a submodule again?
>
> Erupted_v1 has a configuration which uses old derelict-util. Even though I use derelict-glfw to load vulkan, dub downloads both old derelict-util and the new one used by derelict-glfw. This results in warnings because versions mismatch (erupted wants old one while derelict-glfw uses newest).

That's not what I meant. I don't understand why you use ErupteD as dub project AND as submodule. I don't see the advantage of this approach. More specific, if you rely on dub informing you that a new version is out, why use it as a submodule?

> I opened an issue about erupted-v2 on linux as well: https://github.com/ParticlePeter/Erupted-V2/issues/1

Fixed, but the next issue is waiting already. Maybe not the best idea after all. Anyway, lets try the pre-rlease suggestion :-)

>> The GREATER Plan - as promised
>> ------------------------------
>>
>> I want to evolve and learn more about techniques which I have never touched before. This is already great I would think. But fun aside, I would like to look into full automation.
>>
>> 1.) get informed about vulkan-docs updates, trigger automated build process with V-Erupt. Is this possible? Don't know, want to find out.
>
> I think it is possible.
>
>> 2.) setup auto testing for ErupteD-V2. If fail, get informed. Else apply version tag, the same as vulkan-docs. Is this possible? Don't know, want to find out.
>
> It is possible but tests are required. More tests - better.

That's the plan, and that's the reason ErupteD-V1 exists as fallback.