Thoughts on versioning
Paul Backus
snarwin at gmail.com
Wed Oct 27 13:47:26 UTC 2021
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.
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 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
More information about the Digitalmars-d
mailing list