Thoughts on versioning

Paul Backus snarwin at
Wed Oct 27 13:47:26 UTC 2021

On Tuesday, 26 October 2021 at 21:59:33 UTC, Andrei Alexandrescu 
> 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.

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.

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.

So, what if we didn't release N versions? What if we let the new 
library evolve through v2, v3, etc. on, 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?


More information about the Digitalmars-d mailing list