On 10/26/21 1:57 PM, jmh530 wrote:
> On Tuesday, 26 October 2021 at 13:52:01 UTC, Steven Schveighoffer wrote:
>> [snip]
>>
>> After suggesting and exploring probably 4 different mechanisms, including template mixins (which almost worked), I have come to the same conclusion. Just copy and backport fixes when needed. [snip]
> 
> I think the copy and paste approach needs to flesh out the exact procedure that needs to happen at the start of development on that release. For instance, should the std folder be copy/pasted with the result re-named `std_v_x_xx`. This would break code if people stay on std. So maybe the new `std` should be `std2` with folders saved as `std2_v_x_xx`?
> 
> What about creating aliases for each year's release? So for instance, `alias std_yyyy = std_v_x_xx;`? And then increment it as new releases come out each year, until the final one. It would be nice to alias an entire module or package, but otherwise would need to have some automated approach to add in the aliases.

It seems to me the copypasta-and-cherry-pick approach is "well-tried, used by most, takes huge effort and doesn't quite work".

We have a really nice namespace isolation with D and we could leverage it. I would want to give that a solid shake of the stick before throwing our hands and forking 340 KLOC.

One more thing - forking and copying is a one way street. Once we enter there, it's difficult to back off. In contrast if we have another solution we can always change our mind and fall back to forking.

On 10/26/21 5:30 PM, Paul Backus wrote:
> On Tuesday, 26 October 2021 at 19:53:37 UTC, Andrei Alexandrescu wrote:
>>
>> One more thing - forking and copying is a one way street. Once we enter there, it's difficult to back off. In contrast if we have another solution we can always change our mind and fall back to forking.
> 
> If you fork on code.dlang.org, you can change your mind any time you want. The only decision that's irreversible is deciding to ship something as part of the `std` package in the official D distribution.

Agreed. I conflated the moment of "forking" with the moment of "releasing".

The core issue remains the same. Consider e.g. we fork there and we set out to eliminate autodecoding in the new version. Once we release that, we have two trees in two repos on our hands. Back to versioning hell.

On Tuesday, 26 October 2021 at 14:43:19 UTC, Andrei Alexandrescu wrote:
> 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.
I guessed this might have been the motivation, but I don't think regular versions would make things simpler overall.  You'll still have compatibility problems, but it's the library users who'll have to worry about them instead of just the library developers.

On Wednesday, 27 October 2021 at 01:23:44 UTC, Basile B. wrote:
> The A and W API are funadementally there because it's a C API.

That's irrelevant. They do actually overload it with macros.

The point is the old functions - the A ones - are kept around but simply forward to the new functions - the W ones - after doing some compatibility transformations.

That is a viable path for Phobos. The existing std.x functions can forward to std.v2.x as appropriate.