On Thu, Jan 5, 2012 at 9:05 AM, Christoph Breitkopf
a) You are not allowed to remove or change the types of existing stuff. Ok.
Unless you bump the major version number (i.e. X or Y in X.Y.Z.P). That way people can depend on IntervalMap == X.Y.Z.* and be guaranteed that their package won't fail to compile if you release a bugfix to X.Y (which would increase the patch component of the version number).
b) You are allowed to add new functions. But that can break compilation because of name conflicts. Seems to be allowed on the grounds that this is easy to fix in the client code.
I cannot break compilation if you use explicit import lists or qualified imports. People who use that (which I recommend they do) can specify a dependency on IntervalMap == X.Y.* and still be guaranteed not to break if you make a new (minor) release.
c) You are not allowed to add new instances. I don't get this - how is this any worse than b)?
You cannot prevent the import of new instances. When you import a module you get all its instances. This means that explicit import lists can't protect you.
I do understand that it is not generally possible to prevent breaking code - for example if the client code depends on buggy behavior that gets fixed in a minor version update. That seems unavoidable - after all, bugfixes are _the_ reason for minor updates.
Bugfixes you be in bugfix releases (i.e. bumps to the 4th version component.) Yes, if you depend on bugs you might have your code break. There's no way around this. In practice it hasn't been a problem. -- Johan