I did not mean that developers should break things on purpose. Of course, seeking strategies to limit the damage caused by introducing breaking changes, by providing some amount of backward compatibility where possible, is always a good idea.
But I think that what those examples show is that strategies where disruptive changes are introduced on a regular basis (what I call "break early, break often"), requiring some fixes from time to time, work better than strategies where a different branch is used to break the world, and then require a huge transition for users.
Maybe what I failed to articulate in the article is that most compilers, interpreters, libraries introduce minor breaking changes on a regular basis, with most major or semi-major releases. When that amount stays manageable, it's usually not a big problem for users (= developers that use those compilers, interpreters, libraries), that just deal with that.
Also note that real end users are usually protected from this kind of breakage because they use software coming from distributions (that do the work of trying to make sure that everything they ship can work together), or package managers that allow for strict versioned dependencies.
Maybe what I failed to articulate in the article is that most compilers, interpreters, libraries introduce minor breaking changes on a regular basis,
You appear to assume, or even imply, that this is acceptable because it is the norm today.
There are those of us, just like Keith Wesolowski whose reply I cited previously, who vehemently disagree with that implication and that assumption: we represent the engineering ethos of sitting down, thinking things through ("what is it that we're trying to solve?"), and planning ("how can we implement this so that it can be made backward compatible, so we do not break things for users?")
And that's my problem with your essay: that you accept that, because there is so much haphazard hacking without planning going on, it is okay to sometimes (in reality often) break things. I personally do not, can not, accept that things will break because I had been unwilling or even lazy to think things through and plan in advance, or because I had assumed that everyone has the same amount of spare time as I do or did. It's an engineering ethos.
That is not to claim that things will never break, but I can assure you that exceptional effort will be taken on my part to remain backward (and forward, wherever possible) compatible. That's my engineering promise, to all my users.
The core idea of the essay is based on the premise that haphazard implementations are the reality we should simply accept without second thought, and the proposed solution is reactive, not proactive. Tolerating organic growth instead of planning is the root cause.
Also note that real end users are usually protected from this kind of breakage because they use software coming from distributions (that do the work of trying to make sure that everything they ship can work together), or package managers that allow for strict versioned dependencies.
I don't discriminate: users are users to me. Their time is extremely valuable, and I appreciate that all of them use the computer because they want to get something done. They all have certain rights, and deserve to be treated with respect.
Sadly, the computer industry lost a great spirit when Keith Wesoloski decided he had had enough and retired[1], but the engineering ethos is no less valid today than it was when he wrote these words, and lives on in illumos and SmartOS:
In other words, every entry in the test matrix is either identical to
the behaviour seen today or superior. The state of the system has
advanced; its capabilities have improved in newly-built software,
nothing works less well than before, and customers have the opportunity
to apply new capabilities to old binaries if they have the kind of
supernatual awareness of those binaries that the GNU/Linux model assumes
of everyone. Most importantly, the approach is safe: we do not
attempt to change the system's interfaces as presented to existing
software. Those contracts are honoured unless specifically requested by
the customer, with (one hopes) full knowledge of the consequences.
I did not mean that developers should break things on purpose. Of course, seeking strategies to limit the damage caused by introducing breaking changes, by providing some amount of backward compatibility where possible, is always a good idea.
But I think that what those examples show is that strategies where disruptive changes are introduced on a regular basis (what I call "break early, break often"), requiring some fixes from time to time, work better than strategies where a different branch is used to break the world, and then require a huge transition for users.
Maybe what I failed to articulate in the article is that most compilers, interpreters, libraries introduce minor breaking changes on a regular basis, with most major or semi-major releases. When that amount stays manageable, it's usually not a big problem for users (= developers that use those compilers, interpreters, libraries), that just deal with that.
Also note that real end users are usually protected from this kind of breakage because they use software coming from distributions (that do the work of trying to make sure that everything they ship can work together), or package managers that allow for strict versioned dependencies.