We will be following SemVer. However, what is or isn’t considered a breaking change is inherently a bit of a judgement call. Technically, any bug fix is a breaking change since people can and do write code that depends on buggy behavior. In order to guarantee not breaking any possible code that someone could have written, one cannot change anything at all—which clearly isn’t reasonable. (And if that’s what you want, just don’t ever upgrade Julia or packages.)
In some languages, there’s public/private API enforcement, which helps, but Julia doesn’t have that, so we need to draw the line somewhere. The clearest way to draw the line is by testing whether a change actually breaks code or not. Fortunately, we have a very large corpus of code with tests: all the registered Julia packages. If a change seems very unlikely to break real code AND it does not break any packages, that’s pretty strong evidence that it’s a reasonable change even if it’s “technically breaking”. (There may be ways to extend this testing practice to private code as well, which we’ll be exploring in the future.)
The term “technically breaking”, while accurate, is a bit alarming. So we’re calling changes that are technically breaking but which don’t in practice actually break anyone’s code, “minor changes”. There are four minor changes currently slated to go out in 1.1:
- #29061: consistently treat comma at end-of-input as incomplete.
-
#29092: convert values put into channels on
put!instead of ontake!. - #29211: make the printing of BigFloats consistent with other floating-point types.
-
#29274: make “stream unusable” error an
IOErrorinstead of anArgumentError.
These are all technically breaking in the sense that one could write a program that relies on the old behavior and breaks because of the change. Is there likely to be any code in the wild that actually breaks because of these changes? No. In each case, any code that is broken after the change was almost certainly broken before the change as well. For example, if you have a program that puts the wrong type of value into a channel then that program was going to error anyway; now you get the error earlier than you would have before. Could changing the parsing of programs that end with a comma break something? Technically yes, but how many Julia programs out there end with a comma? Not very many, I’d wager. We’ll find out when we run PkgEval. We could always weasel word these changes and say that the old behavior was buggy and that we’re just fixing bugs. But calling these changers “minor changes” seems more direct.