On Tue, Jul 18, 2017 at 11:04 AM Olaf Hering wrote: > But if their usage is legitime, > why the needless breakage? > I like to think of software as sometimes hitting a local optima. That is, to move forward you have to stop the hill-climbing algorithm and start going in the "wrong direction" in order to hit a better spot later on. Every feature in a system is also a liability later on. Hence, any change is a balancing act of keeping backwards compatibility and moving forward. I'd expect some breakage between software releases. Some of these are potential incompatibilities, and in the unlucky case, an incompatibility which noone foresaw sneaks in[0]. The goal is to manage the amount of work it takes to upgrade systems, and possibly provide automated tools to help doing so[1]. Removing features is a great way to move forward. I've often salvaged old code by removing a lot of support for desirable features, revamped the systems core, and then added those features which were truly needed later on. We also learn in hindsight, so many changes eventually have to be reverted. The larger your interface, the more brittle it tends to be. That said, it certainly sounds like a too eager change since 4.06 is not slated for release for a while. But I wanted to ramble a bit about controlled change in a software system. [0] 4 years ago, the Erlang serialization "external term format" was changed to allow for certain symbols to be UTF-8 encoded. Releases would be able to handle the decoding, but would not produce such terms. The recent 20.0-rc1 release enabled the feature since it was believed that backwards compatibility was in place. Yet, it broke systems because they rely on things like the lexicographic ordering of the marshalled serialization, among other things. The final release had to avoid producing the new UTF-8 encoded form if the symbol (atom) was representable in the old (ASCII) form. Erlang highly values its backwards compatibility because upgrades to clusters tend to happen one machine at a time. [1] The Go language used a tool 'go fix' to upgrade breaking changes to the syntax before release 1.0 of the language. This enabled change, yet provided an upgrade path for existing code. 'go fix' is simpler in Go because all code has a default formatting through 'go fmt' so you can just read the AST, change it, render it, and run 'go fmt' on it. The fixes are also rather crude and syntactical. This was no Cocinelle.