by Michael S. Kaplan, published on 2010/10/04 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/10/04/10070978.aspx
Whether one agrees with the Wiktionary definition or not, if you work in software you know what a breaking change is.
Let's look at that definition for a second:
breaking change (plural breaking changes)
1.(computing) A change in one part of a software system that causes other parts to fail; occurs most often in shared libraries of code used by multiple applications
"Not possible to fix old entries without a breaking change, so remap old to new in import lib."
We have had the locale data in Windows for over 15 years now, and every version several things happen:
Literally every version this happens.
Occasionally other stuff has happened too. But these three things represent a cluster of things that has always happened.
Now the interesting philosophical question pops up here, one that I am kind of curious about:
Is each individual change within the second two bullet points above a separate breaking change?
Perhaps the above is an outrageous instance of reductio ad absurdum, though.
I mean, perhaps some changes would not really be reasonably considered to be breaking changes, and some would.
Other changes are there because people saw the unchanged behavior itself as a bug. And dependence on incorrect behavior is always treated as a second class citizen compared to not having such dependencies.
Is there a reasonable manperson standard that could be applied here, in order to determine which types of changes could be reported as breaking?
And, if that is the case, should such reports be given for each change?
Or should there be a list of all the qualifying changes at designated intervals, such as ship dates, or at beta dates?
On the other hand, maybe this is the wrong way to think about the problem, since we actually have an over 15 year history of not treating anything at all as a breaking change, even when the change was in fact later determined to break something.
And I will not lie, that has happened.
There are times in society where the first action a new team takes is to repudiate and assume fault in everything the old team did, but this hardly seems like the most prudent course here. So maybe the old team's approach (to focus on the message that anything in the data can change between versions, so if something of theirs broke then it was caused by their broken assumptions) is the correct way to look at things, rather than focusing on each individual change.
Yet this can also be cast as a form of laziness by someone who disagrees with the idea. They could look at it as someone being afraid to take on a complicated problem.
This point, and how to resolve it, is not a trivial one.
While it is not the most important issue I am dealing with at the moment, it is in the top five.
And it is the most important issue about which I am really able to talk about at the moment.
I am interested in people's thoughts here.
How does the notion of breaking changes fit the model of per version locale changes?
It was just ten years ago today ... on 4 Oct 2010 1:31 PM:
(well, not *today*, actually, but sometime in 2000)
... that I learned that when communicating between independently developed pieces of software, there is *no such thing* as a non-breaking change. Every change, however silly, breaks someone. How do I know? I'll tell ya:
At that time $EMPLOYER was distributing certain files to customers in plain text or in simple HTML, their choice. Each paragraph of the plain text was a single physical line beginning with five spaces so that it would show up indented in plain-text editors. In the HTML version, each such line was wrapped in a p element exactly as-is, including the five spaces.
So I decided to modify the HTML version to drop the five spaces, since they didn't have any effect on HTML renderers anyway. But no. It turns out that some customers were preprocessing the HTML we sent them by removing the fourth through eighth character of each paragraph line without looking at them. So now they were dropping the first five letters of the content instead of a space.
Backed that change out in a hurry.
Moral: Unless you have an agreement in advance about what can be changed, *nothing* can be changed. Ever.
Michael S. Kaplan on 4 Oct 2010 10:04 PM:
Since the locale data does (and has, and must!) change with new versions, the only question is about whether to report any or all of it as breaking (and if so to who and how often)....
Mihai on 5 Oct 2010 9:42 AM:
Kind of agree than any change is going to be a breaking change for someone.
But I would split those affected in two: those who are hit because they did not use the recommended ways to deal with locale data, and those who did the right thing, but had not enough functionality.
To be more clear: if I store locale sensitive data in a file (or use them for communication), and if the locale changing breaks my loading routines, that's my fault. I should store them in a locale-independent way.
But if I parse user input and I was forced to write a parser, it gets a bit trickier. Because Windows does not give me any parsers. So some changes will break my code, but there was nothing I could have done.
So, kind of the rule of thumb: it is a breaking change if you did everything following the best recommended practices, but still get affected.
Well, how is that?
Aaron on 5 Oct 2010 10:43 AM:
I agree with Mihai, except that I would also call out breaking changes if they will break a statistically significant number of 'important' third-party applications, even if they aren't doing things 'The Right Way'.
Michael S. Kaplan on 5 Oct 2010 12:02 PM:
On the end of the telescope that we sit when doing the update, potential impact here is not always known, of course...
referenced by