| Well yes, but then you're de-facto maintainer of that package, you might not have permission to do that, etc - this point though I feel is less important than versioning, it's more an argument for central package control, which has pros and cons If you're using a library from github (or wherever) that isn't open source, and someone takes it offline, that's a legal problem, not a technological one. If you are using an open source library, then just re-upload it (or find someone who will). I don't see why the language has to do anything. What a mess, particular for new users trying to decide which package is best or canonical. Why not just use versions? You know what a mess is? A mess is: * In a Maven build, A depends on version 1 of C, A depends on B, B depends on version 2 of C. Result: Java crashes at runtime. * People using ancient (potentially insecure) versions of Java packages for years because they're afraid of the previous problem. * "deprecated" functions that continue to be used for years, spewing warnings each time they're referenced. * a time-consuming bureaucratic process to get your library into some "blessed" central repository. Go doesn't "support" these messes, and I see no reason why it should. Perhaps Go's dependency management system will change. I can't tell the future. But so far, I haven't seen any good arguments in favor of changing it. All of the problems you think you're solving with versions could be solved by either maintaining backwards compatibility, or choosing a new package name when you feel you have to break it. |