Interesting. But python's package system makes this actively hard to do. From that article: > For example, let’s say you support click^7. Click 8 comes out, an

Interesting. But python's package system makes this actively hard to do. From that article: > For example, let’s say you support click^7. Click 8 comes out, and someone writes a library requiring click^8. Now your library can’t be installed at the same time as that other library, your requirements do not overlap. What I'm arguing for is that click^7 and click^8 should be seen as different packages that (like any other packages with different names) can be installed side-by-side without issue. It sounds weird, but it makes this problem goes away entirely. Nodejs and (I think) cargo both support this. I've never run into errors like this in rust or node. Another advantage of this approach: Integration tests in all previous versions of a package should pass on the current version of that package. I'd love to see test runners which actually enforce this - which should be pretty easy to do in a language like rust where integration tests are clearly separated. Sometimes (rarely) it makes sense to allow an integration test for react16 v1.0 to fail on react16 v2.0, but that implies a violation of semver compatibility. So it should be the exception. Not the default.