| > If you're using a proper type-safe compiled language then most "subtle" breaking changes can't possibly be missed because your code won't compile anymore (assuming you used that API to begin with). You don't need a major version number to call attention to the fact that one parameter of one method changed from a boolean flag to a set of options, anyone who's using that method will find that out pretty quickly. 1. What if it's a dll, .so? You upgrade and find out that your program is broken. 2. Sometimes the API stays the same but the code behind the API changes a result (for example, secure_hash goes from MD5 to bcrypt)? 3. What about non-type safe languages (like HTML or JS, so things like Firefox or Chrome)? The point is that you should avoid breaking other people's code if you can. What happened if that removal of one function in that one module costs me a full years of work? Sometimes you can't help yourself. PHP had register_globals. Some people were able to use it safely (initialize all variables before use), but PHP rightfully realized the security implications and disabled it. However, it broke code, and a lot of it. These are things you should think about and heavily before breaking code. It may be one line for you, but for all the millions of people who use your library it could be thousands of man-years of work. |
If it's not backwards-compatible then it needs to bump the appropriate version number (in my proposal, that would be the second dotted component). So I'm not sure what you're trying to say here.
> * Sometimes the API stays the same but the code behind the API changes a result (for example, secure_hash goes from MD5 to bcrypt)?*
If it's a non-backwards-compatible behavioral change then maybe you need to design your API better such that this kind of change is expressed in the API. After all, if you expect anybody to ever upgrade to your new bcrypt version, you need to provide some path for people to still work with their older MD5 hashes anyway.
> What about non-type safe languages (like HTML or JS, so things like Firefox or Chrome)?
Not something I particularly care about. Though it doesn't really matter anyway; even if you think the breaking change number is too "subtle", anyone who's manually upgrading to a new version instead of letting their package manager do it should already be prepared to deal with breaking changes, because if there aren't breaking changes then their package manager should have been happy to upgrade without any manual intervention.
> The point is that you should avoid breaking other people's code if you can. What happened if that removal of one function in that one module costs me a full years of work?
I have no idea what point you're trying to make here. My suggestion was just about changing the format of the version number, and has no bearing whatsoever on the actual breaking changes you do or don't introduce. I'm certainly not advocating for removing functionality.