Usual reminder that semver defines “breaking changes” as “(public) API breaking changes”. The semantic and syntax of functions part of the public API shouldn’t be changed in a way which breaks existing code, but for example numerical values of functions can be slightly different, especially if it relies on default values of some arguments which can always be customised. This for example applies to RNG functions, Julia documentation contains a warning about the fact the stream of numbers generated by the default RNG can change, but I’m of the opinion this specification is already covered by the semver contract: there is no guarantee you’ll always get exactly same numerical values for all functions across multiple versions, however their semantics shouldn’t change (so for example switching the default RNG of rand to Xkcd221 would be a breaking change because it’d change the distribution of generated numbers, when rand is supposed to give a uniform distribution).
Also, functions not part of the public API can be (and are) broken at will.
I previously misunderstood Stephan’s original quote to mean that “there will someday be a version called 2.0 which will contain breaking changes, or maybe we’ll just call that breaking version 1.x instead”.
We do occasionally make “technically breaking changes” in minor versions. You can find these on GitHub by looking at the “minor change” label—these are changes that are considered acceptable for a minor release. We determine this by a few criteria:
Does the change seem unlikely to cause problems for many people? If the existing behavior is so confusing/broken/unexpected that the change is more likely to fix code than break it, that’s a potential candidate for a minor change.
Does actual usage in the package ecosystem seem to be either unaffected or fixed by the proposed change?
Does the change pass PkgEval tests or does it cause some packages to start to fail tests.
This slides off topic a bit, but since people are already talking here, I’ve been wondering – are there ideas for Julia that are being kicked around that couldn’t be implemented without breaking changes? Features that are widely supported as valuable for Julia but will have to will have to wait for 2.X?
From my relatively uneducated vantage point, Julia seems so flexible that it’s hard for me to imagine what those features would be.
There are always speculative things. You can see Issues · JuliaLang/julia · GitHub . If it ever comes, I imagine it would be when some semantic of the language is holding back a significant positive change. And for now there is still a looot of work that can be done under 1.x .
Yes, there are at least 1 or 2 changes that need 2.0. Changing the precedence of operators would be a breaking change, and |> has arguable the wrong precedence (you can always get the order you want with parentheses, but it’s annoying).
Integer math of Base types, e.g. power, ^ is defined not to overflow (i.e. use modular arithmetic). It’s a frequent complaint. You can get around it by being careful to use Floats or non-standard Integer types, but I think it’s better to change at least ^ and got some support on the issue for it, then it was marked 2.0. So I’m not in real hurry to change it…
While precedence levels are fixed by the parser (now written in FemtoLisp, so not too easy to change, nor wanted), and I thought impossible to change in a package/library, you actually CAN change the parser, as is already done with JuliaSyntax.jl, which will be integrated into Julia. It tries to be compatible, but as a non-default opt-in. Got me thinking, maybe we can (should?) slip some breaking changes in that way… At least since it IS possible in a package, I doubt there’s nothing you absolutely can’t change by using a Julia package (and/or ENV var).