Thoughts on versioning

[Steven Schveighoffer]

On 10/27/21 1:16 PM, H. S. Teoh wrote:
> On Wed, Oct 27, 2021 at 01:04:25PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
>> I'm not seeing the point. Why wrap v2 code when you are going to have
>> to maintain the v1 code anyway?
> 
> I thought the you guys were arguing for making Phobos v1 a thin wrapper
> that forwards to v2 code.  If you wanted to retain a copy of v1 code,
> then this problem wouldn't come up at all?

The point of making a v2 that is separate from v1 is that you can 
include a library that depends on v1 in the same application as one that 
depends on v2, and all work together.

Autodecoding is one of the worst problems, but there are so many more. 
I'll note there is a strong focus in this thread on how to make this 
maintainable from a library side. But not a lot of focus on how usable 
it would be to actually depend on both libraries at once.

Note that if Autodecoding was ascribed to a *custom type* and not just a 
char array, this probably isn't even close to as big an issue.

>> Plus, now it's a template that accepts ranges. Like it or not,
>> `someStringFunc(string)` is not the same as `someStringFunc(R)(R)`.
> [...]
> 
> Point.  So what, does that mean we're stuck with keeping v1 code around
> forever?

I'm fine with just migrating everything to v2 and if you still want v1, 
you go get the old compiler, and good luck to you.

This is what I started with 
[here](https://forum.dlang.org/post/rhbon6$16ve$1@digitalmars.com), but 
it was decided [this was 
undesirable](https://forum.dlang.org/post/rhkf7p$1sto$1@digitalmars.com), so 
I spent a bunch of time trying to figure out how to make tools that help 
with maintaining a v2/v1 split in the same code base, without success. 
Not to say that a solution isn't possible, I just couldn't find one that 
seemed reasonable. Every time I thought I had something that would work, 
I'd run into a critical problem that destroyed it.

Some things that we toyed with, but never implemented, were ways to 
parameterize imports (i.e. same source code, but treated as 2 different 
imports with the package symbols automatically migrated). This I think 
was the most promising, but it is hard to play with if you don't know 
how to augment the compiler.

> Alternatively, here's a different approach: make v1 code a dub package,
> then break upstream Phobos at will to make v2.

I think having dub packages for each major phobos version would be 
ideal. Then you select the package you depend on (and e.g. phobos v2 
could depend on v1 if you want to share code). You still need tools to 
automatically change the imports and things like that (these have to be 
in different packages).

That is, if we want to maintain all-time backwards compatibility.

-Steve