[StefanKarpinski]

We’ve been following semver to the letter:

https://semver.org/

TLDR: if there aren’t breaking changes it won’t be called 2.0 it will be called 1.12 or something like that.

Go is currently planning their 2.0 release precisely so that they can make breaking changes. It was a big deal when they reached 1.0 for exactly the reason that they stopped making breaking changes. Ditto with Rust. We are following the exact same course. If it feels different, that’s because you weren’t using either language pre-1.0.

See also the Python 2 vs 3 transition and Ruby 1.x => 2. Comparing with Perl5 is ignoring the huge changes made in Perl2, Perl3, Perl4 and Perl5, not to mention Perl6.

That leaves Java and C++. Yes pre-1.0 Julia was more breaking than those two, ancient, industrial warhorses.

[attractivechaos]

Which versioning scheme to use doesn't matter. What matters is how long you promise to keep a language "stable". Java and javascript have gone through many major versions, but the core of the language is largely stable. The same will be true to golang. Read their plan [1], the paragraph starting with "Go 2 must also bring along all the existing Go 1 source code". That is promised backward compatibility. There have been breaking changes in Perl5 (so it is not following semver), but most of the changes were minor and little user code was affected. Python 2=>3 is a disaster. If Julia goes through a dramatic change like that in 5 years, it will be worse.

[1] https://blog.golang.org/toward-go2

[StefanKarpinski]

When they write "bring along" they do not mean "Go 2 will be backwards compatible with Go 1". Pre-1.0, Go extensively used "go fix" to automatically upgrade older Go code to newer versions. (If they had never introduced incompatible changes as you seem to be claiming, this would not have been necessary.) They will most likely do the same thing for upgrading code from Go 1 to 2. Although that alone is likely to be insufficient as the failure of py2to3 demonstrates; they will probably need to also support using Go 2 packages from Go 1 or vice versa.

Julia has taken a similar albeit less automatic approach with deprecation warnings. When a breaking changes have been made, in one major release it continued to work but issued a warning telling you how to change your code. Only in the following major version did the code actually break. This allowed people to upgrade, run their tests (you have tests, right?), fix the warnings and be good to go.

More recently FemtoCleaner [1] has been introduced, which automatically makes PRs to projects and upgrades them just like "go fix" does. When we release Julia 2, we'll use a similar approach, so if your happy with how Go is doing things, you should be happy with how Julia does them.

It's fairly straightforward to avoid the Python 2/3 debacle, they key is to always allow packages to support two "adjacent" major versions at the same time, so as to not cause "upgrade deadlock" [2].

[1] https://github.com/JuliaComputing/FemtoCleaner.jl

[2] https://discourse.julialang.org/t/1-0-adoption-path/7922/39

[attractivechaos]

I will ask this more explicitly: how soon will you deprecate features in 1.0? 2 years? 5 years? 10 years? Go 1 is 6 years old and Go 2 seems at least a few years away, and the paragraph I was referring to says "Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years.", which suggests they will keep the Go 1 compatibility for "multiple years" after Go 2 kicks in. That adds up to 10 years. If Julia can promise to keep the vast majority of 1.0 features around for 10 years, I will be good with that.

[vgy7ujm]

For Perl you are forgetting the HUGE amount of code that just works 10-15 years later. I love Perl for many reasons but here is where most other languages gets killed.