It also ensures that your library is going to be a pain to work with on systems that do shared libraries well. Sure, multiple versions can be installed at the same time, but generally, you only want to do that with major revisions -- especially since you need your app to know which version it needs, while at the same time not forcing them to one particular revision.
Yeah, never do that for minor versions. My experience is though, that you'll always first have a long period of development for a major revision, and a couple of clients with immediate interest in it working on those alphas/ betas. During that period, it's fine to break, and you should take the opportunity to sort your API out. Once you've done that, and churned out your first ga release for a major revision, you shouldn't break clients. So yes, like I said, you should want both.
Maybe so. But I also don't necessarily know my way around everyone else's code, so I don't necessarily know best what the implications are if I make the change there. Generally, if it's an incompatible change, it is actually going to require more than just changing the one line in which my method is called.
It also doesn't address the problem of projects that I don't actually control.
Note that I say: "so it's actually *not always* a bad idea to fix yourself"
Maybe so. I think, though, that if you actually remove the old method (interface, API, etc) and provide a new one, that's sufficient to break it. I think the only difference is whether the break happens at compiletime or runtime, but as we're learning now, unit testing is a must for any sizable project, and unit testing is basically trying to break it at runtime.
Unit testing, the wonderful solution for everything, whether it involves syntax checking or API evolution. Sorry, but I don't buy that.
