3 ms·

I'd differ on this a bit. Your N+1 scheme is fine with me if you want to use the newest and greatest features, but I think old code / libraries should still wor

I'd differ on this a bit. Your N+1 scheme is fine with me if you want to use the newest and greatest features, but I think old code / libraries should still work so long as they don't use the latest and greatest features. I think the compiler should just ship with older versions of the language and different translation units can be compiled with older versions of the compiler. So long as the newer versions can interact with the older ABI (which ideally rarely changes), there's no problem.

bee_rider 5y ago
In that cast, they'd have to either * Fix all bugs in old version, or * Ship known buggy code Neither seems great. Better to just have archival versions with a "here be dragons" warning.
- morelisp 5y ago
  > Ship known buggy code Thank god there's no known bugs in released software!
  - deleted 5y ago
    [deleted]
  - bee_rider 5y ago
    I'm not sure I follow.
    - morelisp 5y ago
      Go 1.17 will release with a lot of known bugs. Continuing to ship it a year later with known bugs is not different. But more deeply, LTS ships buggy versions of the software. That's the point - only the truly dangerous bugs (e.g. compilation-triggered RCE or something) get fixed, everything else stays compatible even if it's otherwise undesirable or suboptimal. Code depends on those bugs.