Thoughts on versioning
mail at skoppe.eu
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