version(number) is completely useless

[Mike Parker]

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?