Vulkan ErupteD breaking changes and transition strategy

[ParticlePeter]

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/