Thoughts on versioning

[Andrei Alexandrescu]

On 10/27/21 9:47 AM, Paul Backus wrote:
> On Tuesday, 26 October 2021 at 21:59:33 UTC, Andrei Alexandrescu wrote:
>> 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.
> 
> It seems to me like you only really end up in versioning hell if, after 
> releasing v2 in Phobos (and committing to no further breaking changes), 
> you go on to develop v3 (with new breaking changes) in the same repo. 
> Otherwise, you can just mirror changes from the Phobos version to the 
> dub version.

On the contrary, I see repeated mirroring of changes hell, and mindful 
departure by a mix of reuse and rewriting much easier.

At least there is evidence in the way everybody maintains versions now 
that mirroring them changes is NOT easy. It remains to be seen whether 
better language support for versioning will improve the matter; I am 
hopeful it does.

> I think the root of the problem is, releasing N versions of the Phobos 
> API means you are committing  to maintaining N versions of the Phobos 
> API, more-or-less indefinitely. And with annual or even triennial 
> releases, this maintenance burden will quickly grow beyond what the D 
> community can handle.

We can and we should establish a retirement schedule.

Minimizing effort is exactly why I'm trying to improve on the status 
quo. Do we agree that extant methods of maintaining multiple versions is 
difficult?

> As Steven Schveighoffer points out [1], having all N versions in the 
> same tree does not really save you here--it gets you out of versioning 
> hell, but you end up in #ifdef hell instead.

There is no ifdef hell. The new version of a library either redoes an 
artifact or reuses it. Really the new version is a delta over the old.

> So, what if we didn't release N versions? What if we let the new library 
> evolve through v2, v3, etc. on code.dlang.org, and only released it into 
> Phobos when we were well and truly done with it, and willing to commit 
> to supporting its API long-term?
> 
> [1] https://forum.dlang.org/post/sl9161$2ntu$1@digitalmars.com

I think breaking std would be a disaster.