Versioned Roots

[LightBender]

This part of the document is not well specified and I am highly skeptical of the design it implies. No other language does it this way and I suspect that there are good reasons for that.

When I asked @WalterBright for more detail on the design, he explained it to me as follows:

It is about making a hierarchy. std3 overrides std2, std2 overrides std. That way, any code using std or std2 will still work without changes. Think of it like:

class std { }
class std2 : std { }
class std3 : std2 { }

I presume that this is done via some sort of public import hierarchy? I can foresee a few problems with this.

1. This make it significantly more difficult to exclude older code that we don't want to support anymore in newer versions. This is due to public import being an all-or-nothing tool.
2. This will monotonically increase compile times as the number of versions climbs in two ways. First, we'll have to read ever more files off the disk to satisfy the public import. Second, all imported modules will have to be compiled even if they are eventually unused.
3. No other language does it this way. This will be extremely confusing to new users who are used to have a "unversioned" library (C++/Java/.NET/etc.). It will also cause confusion on where features are located (is that in std3 or std4?). While that's not a problem when using the latest version, it absolutely will be confusing due to the "crippled by default" design of editions where the oldest edition is the default (that's a separate discussion of another bad idea that nobody else does).
4. This entire problem set can be handled with Git. Each "version/edition" gets it's own branch in git, fixes can be shared across branches, then shipped with the appropriate edition. There is no need to add this complication and confusion.

That covers my questions, if anybody else has any other Pro's or Con's to the design they'd like to add, I'm most curious to see them!

@WalterBright @schveiguy @atilaneves

[atilaneves]

I think your points are all valid. The issues are more to do with not rewriting code, which @schveiguy tried to get around with template mixins, but that introduced problems too. Then there are template constraints that come from a different version of the library.

I'm also not sure yet how this interacts with editions or not.

[LightBender]

Why would we be rewriting code? Isn't this the purpose of branches? For example, the master branch is always vNext, when we cut the "Phobos3" release that gets branched and becomes it's own thing, that way we can cross-apply fixes appropriately between branches.

IMO, trying to support multiple versions of the library in the same application is a fools errand. At best we're going to end up in our own version of DLL Hell. For example, if I want to rewrite an old version of a Phobos method to use some new compiler trick that's not available when the original version was cut, I can't because it's in an old root-version. And if I did rewrite it in that root, the library would no longer compile without the newer edition. But, if you version with branches the same way everybody else does, I can rewrite in the vNext branch without touching the older branches.

Every time I look at this idea I come up with more reasons not to do it.

As to how this ties into Editions, my first thought is that I'd want to tie a major Phobos release to a Compiler Editions, that way we can clearly delineate what compiler features are available to the library writers for a given major library version.

[atilaneves]

Editions might/will mean keeping around old version of Phobos. Think std::auto_ptr in C++.

[LightBender]

git checkout -b v4
git tag v4
git push origin v4 --tags

The present design is seriously over thought. This is something that is handled innately by Git and it's going to do a much better job than we can, plus it makes cross-applying bug fixes to multiple editions simple. It is trivial to maintain multiple versions of a codebase in Git.

[atilaneves]

We also had discussions about using branches and IIRC Andrei had some misgivings but I can't remember exactly what they were. It might be because at some point there will be 20+ branches, and managing cherry picks and merges will be... challenging. There are trade offs all over the place here and we have to make hard decisions somewhere.

[LightBender]

Walter and I discussed this in our Phobos 3 design meeting and I learned that it was never his intention to imply that the number in the proposed root name was a version. We both agreed that this was not a great design choice and to look for something else.

As such I am closing this discussion as it is no longer useful. Please see this discussion instead.