> In dependencies I import I want a perpetual v1 which doesn’t change over a decade and just slowly improves, not v31 - new improved rewrite this year!
> Which this rule explicitly encourages.
I agree with the first part (I'd much prefer having a MyFunction2 in a package if necessary, than a breaking change to the package itself).
But my takeaway from the design was the exact opposite - that it discourages breaking changes, by making them a little less convenient, and that the purpose of the feature was to allow major versions to simultaneously exist to avoid build issues [1]. I think I got that impression by reading the long articles that the team lead put out about the design decisions [2], and observing that the standard libraries themselves rarely break compatibility.
Unfortunately watching various discussions some people do feel encouraged to put out new major versions since upgrades are "solved" (even though that's only from a build system perspective, you're still causing client churn).
> Which this rule explicitly encourages.
I agree with the first part (I'd much prefer having a MyFunction2 in a package if necessary, than a breaking change to the package itself).
But my takeaway from the design was the exact opposite - that it discourages breaking changes, by making them a little less convenient, and that the purpose of the feature was to allow major versions to simultaneously exist to avoid build issues [1]. I think I got that impression by reading the long articles that the team lead put out about the design decisions [2], and observing that the standard libraries themselves rarely break compatibility.
Unfortunately watching various discussions some people do feel encouraged to put out new major versions since upgrades are "solved" (even though that's only from a build system perspective, you're still causing client churn).
[1] https://research.swtch.com/vgo-import
[2] https://research.swtch.com/vgo