www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Vulkan ErupteD breaking changes and transition strategy

reply Peter Particle <ParticlePeter gmx.de> writes:
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
Mar 25 2018
next sibling parent reply Anton Fediushin <fediushin.anton yandex.ru> writes:
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.
Mar 26 2018
next sibling parent reply Seb <seb wilzba.ch> writes:
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
Mar 26 2018
parent reply Anton Fediushin <fediushin.anton yandex.ru> writes:
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.
Mar 26 2018
parent Seb <seb wilzba.ch> writes:
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.
Mar 26 2018
prev sibling parent reply ParticlePeter <ParticlePeter gmx.de> writes:
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/
Mar 26 2018
parent reply Anton Fediushin <fediushin.anton yandex.ru> writes:
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/
Mar 26 2018
parent reply ParticlePeter <ParticlePeter gmx.de> writes:
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
Mar 26 2018
parent reply Anton Fediushin <fediushin.anton yandex.ru> writes:
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.
Mar 26 2018
parent ParticlePeter <ParticlePeter gmx.de> writes:
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.
Mar 26 2018
prev sibling parent ParticlePeter <ParticlePeter gmx.de> writes:
On Sunday, 25 March 2018 at 22:23:06 UTC, Peter Particle wrote:

 ErupteD [0] is deprecated (one of its major modules).


[snip]



Rewind and Undo
---------------

I must apologize for the mess I have created, ErupteD is 
un-deprecated again. It will be further developed until 
ErupteD-V2 has a proper automation and testing system in place. 
There will be a separate announcement, when ErupteD v2.0.0 
reaches vulkan 1.1 status.
Mar 27 2018