Thoughts on versioning

Sebastiaan Koppe mail at
Wed Oct 27 07:44:19 UTC 2021

On Tuesday, 26 October 2021 at 14:43:19 UTC, Andrei Alexandrescu 
> I regret I forgot to mention in the initial post that we're not 
> looking at v2. We're looking at v2, v3, v4, ... released e.g. 
> at an annual or trienal pace. It's the having a fish vs. 
> knowing how to fish problem.

That does change things. Obviously the copy/paste approach isn't 
going to work then.

Whenever people have to maintain several versions of a product 
what they often do is to implement the old version in terms of 
the new. From the outside it seems version 1 is still available 
but internally it is just version 2 + the quirks of version 1. 
That might not be possible everywhere, especially if the newer 
versions stray too much.

It is not much different from what you propose, except that it 
doesn't penalize all the code to have extra version boilerplate 
around it (mixins, alias module). That might not be possible in 
certain cases because of a too intrusive change, where you can't 
write version 1 with version 2, and you either have to copy it 
(if it is small) or wrap it in version/behavior-selection code.

You can end up in a situation where most of version 1 is 
implemented with version 2, except for a few annoying bits here 
and there. Which would also be acceptable as long as it isn't too 
much. The unanswered questions are "what is too much?", "how to 
measure/detect", "how to mitigate?".

Ultimately it depends a lot on how well you can extract generic 
code usable for both versions. If the ratio generic code to 
version-specific quirk code is favorable then it can definitely 

It goes without saying, do this all in one repo please.

More information about the Digitalmars-d mailing list