Vulkan ErupteD breaking changes and transition strategy

[Anton Fediushin]

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/