On Saturday, 23 July 2022 at 00:33:36 UTC, Hipreme wrote:
> Trying to use numbers on version doesn't seem to be what you have planned.
I believe the naming could be feature(A)
instead of version because it would make a lot more sense. In my case, I have been coding a game engine which you can turn off or on a lot of features like: version(JSONParsing)
version(XMLParsing)
, which it is easy to understand exactly what is happening, but it actually does not really reflect what a version is.
What is a version? Linux version, Windows version, free version, licensed version, alpha version, beta version, gold version...
version
is about more than just individual features and is broader than "project version number".
> But, how one would approach when the feature is version dependent? This becomes a lot harder to reason about, the version number could mean anything.
You can use the approach I already recommended with static if and enums. Then you get to define exactly what a version number represents (e.g., only features from 2.5.2 or all features from 2.x). I know Walter doesn't like it, but it works great.
You can also use your build system to set up specific configurations of version combinations.
> Specially approaching bindings, which other languages already has that convention of making/not making available functions based on version, it becomes even harder when this function can be enabled/disabled and is even build version dependent
Consider again my bindbc bindings. SDL remains backwards compatible on ever minor version, so the API of 2.5 is still available in 2.10. Then there's Lua, which removes or renames C API functions in almost every minor release. Static if + enums allows me to handle both cases with version(SDL_NNNN)
and version(LUA_NNNN)
.
version
is very simple and easy to understand. Why would you want to add complexity to it when you can already do what you want to do?