Hi Branden, >>> I need you and Ingo Schwarze to understand that "behavior >>> change" is not synonymous with "regression".
>> This sounds like a straw-man reduction of both our positions. > I wish it were. I _want_ it to be! Meaning: I want the straw man to be > a distortion I don't have to deal with. The problem I face is that > neither of you articulate a limiting principle to what you characterize > as "regression" [...] Oh, that's fairly easy to answer, though the answer cannot be very rigorous. First, we need to realize that regressions, gratuitious changes, and improvements form a continuum, rather than being rigorously distinguishable classes. First, let's define the extreme cases: * A change in behaviour is a clear regression when it causes idioms to no longer work that are commonly used in code or documents, and the decision to deliberately break compatibilty has not been made based on widespread consensus that there are very strong reasons the change is needed and no less disruptive way can be designed to solve the underlying, very serious problem. * A change is clearly a gratuitious change when the improvement is of a very minor nature, in particular when it causes inconvenience for some users and there is no consensus that it is a clear improvement at all. * A change is clearly an improvement when it is fully backward compatible (meaning that code and documents that worked before still work afterwards) and there is consensus that it provides significant benefit, for example improved security, significantly simplified usage, or very important new functionality that does not bloat the user interface. Obviously, edge cases exist between regressions and gratuitious changes on the one hand and between gratuitious changes and improvements on the other hand. The way to deal with edge cases is to build consensus and only change behaviour when consensus is reached. When consensus cannot be reached, a solution should be sought that addresses the underlying issue as well as possible without causing new problems for part of the community. For example, from 1.23 to 1.24, the default in groff_man(7) and groff_mdoc(7) was apparently changed from -rLL=78n to -rLL=80n. In my book, that is clearly a gratuitious change, not an improvement, because the benefit is very minor at best, if there is any benefit at all. I think is is almost impossible to make any strong argument in either direction why one is better than the other; there are only weak arguments like "let's improve the efficiency of terminal real estate usage by 2.5%" or "this might make diff(1)s between formatted manuals look ugly in 80n-wide terminal windows" or "coming so close to the right margin looks ugly" - so this mostly boils down to personal preference. However, even though none of the options is clearly better than the other, *changing* the default causes disruption for some people. For example, is that change important enough that changing every single one of 524 (five hundred and twenty four) desired output files in the mandoc test suite is a consequence worth accepting? Changing 524 files and making sure the change to each of the files is completely correct does cause significant effort, you know. For example, is it worth disrupting the project goals of the mandoc project? As you know, the main goal of the mandoc project is compatibility with groff. As a secondary goal, any software project obviously also wants to be compatible with itself. But such a change makes that impossible: i can no longer maintain compatibility with both groff-1.23 and groff-1.24 and compatibility among mandoc versions. For example, is it worth confusing innocent bystanders like these poor guys in the pod-perldoc project: https://github.com/briandfoy/pod-perldoc/pull/79#pullrequestreview-3725604410 (By the way, thanks to Andrew Fresh (afresh1@) for making me aware of that confusion over there.) What exactly is the significant benefit justifying all this disruption? Yours, Ingo
