Near 300 packages are failing

[Dahua]

Looks like we have to be busy for a while to fix them ...

[Miles Lubin]

No complaints here, having fast tuples is definitely worth it for us.

Jeff & crew, when might we expect a feature freeze for 0.4? We'll definitely need to give package developers some time to adjust to the syntax changes and clear out the deprecation warnings.

[Jeff Bezanson]

I think there are only three or four major issues left in 0.4:

syntax: separate array concatenation from array construction #7128
Taking vector transposes seriously #4774
range indexing should produce a subarray, not a copy #3701
(MAYBE type-inference-independent comprehensions #7258)

The rest are fairly minor, and tend to be either bug fixes or items
where we just need to make a decision.
Ideally, I'd like these to be done in 5-6 weeks and declare a feature
freeze at that point. After that we have about a month to release 0.4
in time for JuliaCon.

[Dahua]

Make no mistake, I also appreciate the new changes to tuples.

That being said, the wide spread breakage is real, which does lead to various issues on package development. I guess a more graceful transition might be possible (e.g. notify package authors in advance, and allow a certain period when people can work with the breaking branch and prepare the package for the new change)

[David Anthoff]

> Ideally, I'd like these to be done in 5-6 weeks and declare a feature freeze at
> that point. After that we have about a month to release 0.4 in time for
> JuliaCon.

Release as in final release? I think that timing is too aggressive. I would assume that a lot of package devs are waiting for a feature freeze on 0.4 before they start to address 0.4 compatibility (certainly I am). So that would leave one month to address all compatibility issues in packages, which seems way too little time. I would hate if 0.4 comes out and is not really usable because a large number of packages are broken.

I would prefer if there is a) more time after a feature freeze (at least two months?), and b) that 0.4 only be released once a significant number of packages are compatible (especially high use packages).

Also, how about designating a feature-freezed version as beta, and then have release candidates from there on out?

[Tony Kelman]

I think the plan this time around is to transition from 0.4.0-dev to 0.4.0-pre as a "soft feature freeze" once the final breaking changes are in, but leaving time for stabilization and remaining bug fixes, cleanups, etc. Then tag a release candidate 1-2 months after that (and branch release-0.4, then change master to 0.5.0-dev to open for breaking changes again). I agree that a final release in time for JuliaCon is over-optimistic, but maybe an rc1 tag by then depending on how the remaining array changes go.

[Marcus Appelros]

We can write a find & replace AI script that fixes them all automatically

[Viral Shah]

Yes, I think the array stuff is the only major thing that we want to get done in 0.4. These are major breaking changes, and I'd love to get them into 0.4.

Realistically, I think these changes are going to happen in the next 3-4 weeks, after which we can announce the freeze. After that, we will probably need another 3-4 weeks to sort out all the packages and various performance issues all over the place, and we can do a release candidate. The final release is most likely another 2-3 weeks after the first RC.

For a high quality 0.4 release with all this, I think our timeline is:

1. May 15: Get all array behaviour changes and announce feature freeze.

2. June 15: Release candidate 1

3. July 15: Release 0.4

There is the slight possibility of 0.4 release at JuliaCon, but I think we will all be busy with travel and JuliaCon planning, and realistically, there may be RC2 or something at the JuliaCon hackathon, and final release in mid-July.

-viral

[Viral Shah]

I guess this is essentially the same as what Tony outlined.

-viral

[Iain Dunning]

Update: situation with packages on 0.4 is improving already: http://pkg.julialang.org/pulse.html

[Toivo Henningsson]

Has the official policy for handling this change while maintaining Julia 0.3 support been stated anywhere? I guess it is to use the new syntax but put @compat() around it? (And use the Compat package)

[Tony Kelman]

Unless someone comes up with a better option, the closest thing we're going to get to an official policy is exactly this.