by Michael S. Kaplan, published on 2010/10/15 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/10/15/10076268.aspx
"Breaking changes" is often referring to the contract of both an interface's definition and its behavior, which makes it one crazyass metric.
Much moreso for the latter than the former, because the former's "break" potential is direct a compile-time issue, while the latter'as "break" potential is a nebulous theoretical issue once you move past the "elementary school" issues of exception types.
Bundlng all of this in one place is ridiculous since it is like bundling up your apples with your seas otters.
Take me word for it, this is a bad idea; when I have done this in the past, my sea otters have eaten my apples every time.
So for the rest of this blog, let's assume I have added a define:
#define BREAKING_CHANGE SutbleBehaviorChangesThatBreakAppsWhenYouMayLeastExpect
and just make that part easier, since the problem I am limiting the definition to is enough on its own....
You may have noticed earlier this month that when I wrote Figuring out the applicability of the term "breaking change", I palmed a card there. Lots of you didn't but a few of you did.
What did I do?
Well, by focusing only on the behavior at two levels of granularity:
the simple fact that every version is guaranteed to have changes makes the second level a guaranteed expectation of a breaking change that every application simply must assume as both past behavior and future intent will apply their own behavioral correction on anyone who refuses to allow the facts to intrude on their world view.
Note that .Net 4.0 forces managed code developers to learn the same lesson for managed culture changes, an issue they were largely shielded from in all previous versions!
That blog post is a very reasonable method of framing the question in a way that lets one control the direction the conversation will take.
If you read it, then sorry if you feel manipulated. :-)
Now it is time to widen the problem a bit and see if I can make the issue a little more complicated!
We'll start with the rule.
The main rule.
The rule we never never never want to break.
We never change locale data except in new OS versions.
Even after we make a change in a new version, we do not go back and change prior versions.
Easy, right?
There are very good reasons for this, but one of the most important ones relates to both managed code that parses data formatted according a specific culture and any work that another developer has done to do the same thing with locale-specific formatting. Because if any of the formats change within a single version then code that would never have broken can suddenly break.
And that is lame, when it happens.
So from a "breaking change" application compatibility standpoint, this is a very careful and deliberate rule that avoids breaking customers.
Then of course every good rule kind of begs for an exception.
And that exception?
Currency updates with the likely potential of huge impact on large customer segments that have a reasonable expectation of the change occurring.
Both the initial update of many countries to change their currency to the Euro and later updates as new countries joined the Euro zone were judged to fall into the category carved by this exception. And thus far every country moving to start using the Euro as their currency has enjoyed this privileges of membership of this category
Other updates with smaller impact have had mixed results -- some have been taken even when only some of the dimensions of this exception's requirements are proven, many more have not.
Each of those two groups will have both people in it
I won't go so far as to say there is always a completely consistent bar applied here, because the decision is so often dependent on how compelling of a case is made and how backed up by facts it is -- above and beyond the obvious objective points like "national standard" and such -- and those more subjective requirements can often drag the issue either over the finish line or into the penalty box, by the time all is said and done.
You may even have your own examples of the past in your mind as you read this blog.
And perhaps even prior blogs on Turkish or Kazakh or Paraguayan, and so on. I suspect it will always be this way.
Okay, now that I have tried to outline everything in a way that I think is all reasonable, it is now your turn to rip holes in this and explain why too much is changing, or not enough is.
Ready? Set? Go!
Mihai on 15 Oct 2010 10:52 AM:
Here is another exception (hidden for now, and hopefully not manifested too soon): the Japanese era. It is now possible to add some more by changing the registry. And that feature might be needed at some point. With even shorter notice than a currency change.
Michael S. Kaplan on 15 Oct 2010 10:59 AM:
Yep, I've talked about that one before too. But I didn't want to seem morbid. :-)