Continuing the discussion from PSA: Julia is not at that stage of development anymore:
I was under the impression that semantic versioning requires that version to be called Julia 2.0. I would be sad if we introduced a bunch of breaking changes in Julia 1.x for any value x.
If this is the case I request that someone edit the PSA to delete “or we wouldn’t call it 2.0, we would just call it Julia 1.x for some value of x.”
1.x will never contain any breaking change. That’s what he meant. That if the changes are not breaking, there is no reason to call it 2.0.
If a version introduces breaking changes intentionally (unintentional regressions are fixed after all), that version will have to be called 2.0. Any other version (non-breaking) is a 1.x.
There will not be a 2.0 in the foreseeable future.
I think the original sentence is clear enough, but perhaps:
There will be a time when we start working on Julia 2.0 in order to include breaking changes. Otherwise we won’t call it 2.0, we would just call it Julia 1.x for some value of x.
is a tad clearer?
Or even “We will only call something 2.0 if we plan to include some breaking changes, otherwise if there are no breaking changes we will continue to make versions 1.x”
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”.
Thanks for the clarification.
Other things that tend to change (and are not considered breaking) are display, and some types (especially error types, but not only). Example:
julia> typeof(sin∘cos) # Julia 1.8
ComposedFunction{typeof(sin), typeof(cos)}
julia> typeof(sin∘cos) # Julia 1.0.5
getfield(Base, Symbol("##52#53")){typeof(sin),typeof(cos)}
Occasionally return types will also change, which can be breaking if you’ve defined custom methods based on those return types, e.g. Swap adjtrans and triangular wrappers by dkarrasch · Pull Request #38168 · JuliaLang/julia · GitHub
One thing to understand about semver is that “breaking” has a narrow definition!
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:
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.
I think the other types of change not usually considered to be breaking are:
more details (although this guidance is about packages, not specifically Julia Base): GitHub - SciML/ColPrac: Contributor's Guide on Collaborative Practices for Community Packages
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).