Yes, 0.6 will be the last release before 1.0. New features that are backwards compatible can be introduced in 1.x versions before 2.0. Backwards incompatible changes have to wait until 2.0.
Can I ask, I know it’s hard to predict, but how much time do you predict between backwards-incompatible (major) releases post 1.0? I guess there is a tradeoff between too much churn (annoying users), and releasing a whole swath of changes simultaneously (resulting in fragmentation e.g. python 3). I note that Swift seems to be doing this roughly yearly so far…
It is hard to say, but I think that we should probably not wait as long between major versions as languages have in the past and follow closer to the Swift model – especially if we can provide really good tooling to make upgrading smooth. And of course, if we’re going to break compatibility, we need to also add really worthwhile new features to motivate taking the trouble of upgrading. Julia 2.0 could maybe be two years or so after 1.0 – but that’s a pretty big guess, and we’ll have to see how far we can get with backwards compatible 1.x releases and whether there are really compelling backwards incompatible changes that we want to make.
Removing a deprecation is a breaking change. It’s debatable whether adding a deprecation should be considered breaking - considering how slow having deprecation warnings makes code, I’m of the opinion that adding deprecations shouldn’t be done between 1.x and 1.y releases either.
I don’t believe I ever said that 0.6 would definitely be 1.0-alpha, although we are certainly trying to frontload as many breaking changes into 0.6 as we can. There will, however, still be changes between 0.6 and 1.0 or there wouldn’t be much point in going through the additional release cycle.
It remains to be determined how we handle deprecations post 1.0. Once 1.0 is out, there will be a collective process of stop, relax and contemplate how we continue from there.
They are all pretty small PRs and (I believe) fairly uncontroversial. It is my opinion that the test output PRs significantly improves the user experience for the testing framework.
I should add that if you’ve got commit bit and you want a PR included, putting the 0.6.0 milestone on it is helpful so that it shows up in the appropriate PR search.
Certainly feature freeze has been extended by at least one month. But with the type system revision being merged, the most important major feature is now in, no?
Some of these are not breaking so can happen after feature freeze – about half of them are behavioral changes and need to get merged first. Fortunately, they’re all pretty far along.