On Friday, May 01, 2015 10:40:46 Daniel Kozak via Digitalmars-d wrote: > I do not want to change any of the issue above, I just do not understand why > some breaking changes are OK, and some other are not so ok.
Well, fixing bugs often results in breaking changes. Sometimes, it's determined that something causes enough bugs that we make it illegal (e.g. implicit fallthrough in switch statements), and that would be a breaking change (though in principle, it finds and prevents enough bugs to be worth it). Sometimes, we're forced to make changes in the language to enable something we want or need to do or to make an existing feature work correctly, and that can result in breaking changes. Sometimes, we decide that a previous design decision was enough of a mistake to be worth changing even though it breaks code. There are a number of reasons for it. Ultimately, the question is whether the changes are worth the problems that the breakage causes (which often depends on how much code is likely to break and how critical it is that the change be made; e.g. fixing a bug is pretty much always going to be worth the breakage, whereas making a design change often wouldn't be). And whether the change is made tends to depend on who's involved in the decision. Some devs are more willing to make breaking changes than others, and it's not always clear whether something is really a bug or just an unfortunate result of other design decisions. Walter tends to reject most breaking changes, but he might consider something to be a bug that needs to be fixed whereas someone else thinks that it's legitimate behavior. And Walter doesn't review every pull request, so sometimes, breaking changes are made without his knowledge or consent. We make _far_ fewer breaking changes than we used to, and the bar has been raised considerably, but we do upon occasion make breaking changes when we think that it's worth it, and that's always going to be on a case-by-case basis. So, it's very hard to give a definitive answer as to what is and isn't an acceptable breaking change. It really depends on the change in question. In general, I think that most breaking changes occur due to regressions that aren't caught, in which case, they're bugs, not purposeful changes. And while we're doing better at catching and preventing regressions, we definitely don't get them all. We really need more folks trying out the betas with their projects and reporting any issues that they find in order to get anywhere near catching them all (and we'll probably never catch 100% of them, particularly if a regression affects only rare cases). So, frequently, code breakage is completely accidental. - Jonathan M Davis
