0.6 release timeline

announcement

#1

Here’s the 0.6 release timeline:

  • 0.6 feature freeze: Dec 31, 2016 – implement it by then or it’s not going in 0.6
  • 0.6.0-alpha: early Jan, 2017 – great time to update packages to support 0.6!
  • 0.6.0-beta: late Jan, 2017 – no, seriously, update your packages for 0.6
  • 0.6.0-rc.1: early Feb, 2017 – whenever all release-blocking issues are closed
  • 0.6.0 final: late Feb, 2017 – whenever an RC lasts a week with no new issues

The feature freeze means that anything that you want to have as part of 0.6 needs to be completely implemented by the end of this month!


Teaching julia starting 20 jan. v0.5 or v0.6?
#2

Very good to know! Could you say anything about v0.5.x bug fix releases, up until v0.6.0 comes out?


#3

We try to do them monthly, but bandwidth is a bit limited so sometimes it doesn’t happen.


#4

is 0.6 the last feature release before 1.0?

Either way, how long until post 1.0 features hit stable versions? Are they kept until 2.0, or can backwards compatible features be release earlier?


#5

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.


#6

Thanks for the update, Stefan.

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…


#7

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.


#8

Another two clarifications:

If I remember your JuliaCon talk correctly, 0.6 is 1.0-alpha. So, can new, breaking features be added after the 0.6 freeze but before 1.0?

How will the whole deprecation cycle work post 1.0? Will deprecations stay for a whole major release, or just for the first of its minor ones?


#9

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.


#10

Is this going to make it in 0.6? https://github.com/JuliaLang/julia/issues/5155

If not, it will have to go in 2.0, right?

What about the array buffer? I assume it’s not breaking.


#11

Yes, #5155 is still planned for 1.0. A buffer type could also still make it.


#12

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.


#13

#14

If anyone has any PRs that they want merged for 0.6 that are languishing or have gone stale, now’s the time to bump them!


#15

It would be nice if someone more than Tony could look at



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.


#16

Reviewed 'em. In favor of all three.


#17

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.


#18

What is the current plan here? Is the timeline at the top still on?

Cheers,
David


#19

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?


#20

This is the current list of 0.6.0 PRs that we’re trying to merge:

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.