That's certainly an interesting case. A "UUID" package is a good example of this, since UUIDs are often not in the standard library, but are often passed around

That's certainly an interesting case. A "UUID" package is a good example of this, since UUIDs are often not in the standard library, but are often passed around between other packages. There are two approaches to solve this that I know of: 1) When releasing UUID 2.0, also release a new UUID 1.X which adds a dependency on the new UUID 2.0 package. Then either: a) Re-export the UUID 2.0 type from the UUID 1.X package. b) Add conversion functions/operators to the UUID 1.X package. This approach is nice because there is no extra overhead for the 2.0 dependency, all of the extra compatibility code only exists in the 1.X package. 2) Discourage passing around UUIDs directly. Instead have a trait/interface/etc. called "UuidLike" or similar, that is implemented for UUID-like things, and have downstream code be generic. This trait would allow converting to/from any version of the UUID type. A similar approach as in (1) can be used to share this trait across multiple versions of the package. For this example of a UUID, approach (1) makes more sense to me, but in practice there may be cases where approach (2) makes more sense. There may also be cases where it is preferable to just break compatibility. An example of this would be if the UUID 1.0 package had a sufficiently serious design flaw (eg. always assumed type 1 UUIDs or something). In that case the ecosystem churn may be preferable than trying to support something inherently broken.