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.





Reply via email to