Vulkan ErupteD breaking changes and transition strategy

[ParticlePeter]

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