PSA: use Julia 0.7 if you are upgrading

Yes. After this process, it has occurred to me that it might have been better to release 1.0 with deprecations and then delete them in 1.1 but that’s not what we did, but that occurred to me only after the fact, so ¯\_(ツ)_/¯

10 Likes

Will the (minor) changes in the short run be backported to v0.7?

1 Like

In case you use 0.7 to upgrade a package: do test on 1.0 as well, even if it is without warnings on 0.7. Two possible gotchas are overloading a method that no longer exists in Base and the fact that precompile is the default in 1.0.

8 Likes

Everyone makes mistakes, but not everybody is able to confess his mistakes. Thank for all the work.

7 Likes

What would have happened if Pkg3 in 1.0 were to have assumed an upper bound on dependencies in legacy REQUIRE files, so that only releases tagged for 1.0 could be added? Would that have made things better or worse from a new user perspective?

I think this could be very confusing for people new to Julia (and maybe even not so new). Is it reasonable to turn errors into deprecation warnings in 1.0 (or 1.0.x )? And then release 1.1 ASAP, when most packages are upgraded ? I know that’s what 0.7 is for, but it would be easier for people to understand and lessen the potential backlash.

I’ve worked out some heuristics for when a package is or is not compatible with 0.7 which I will try to get into the script that generates the General registry soon.

btw: How should i understand “Unfortunately that’s a bug in Julia that is fixed on 1.0 but not on 0.7.” that was recently on slack (by staticfloat?). I thought 1.0 is 0.7 without deprecations only?

Your advise will just reach users who follow this mailing list. New users will see the 1.0 download button on julialang.org and go try to download the 1.0 version without reading the fine prints below the download link, only to get frustrated and post on discourse.

Should your advise be made clearer in the julialang.org main page?

5 Likes

And a few bug fixes that didn’t make it into 0.7.

I guess the consequences depend on how many popular packages are not yet upgraded for 1.0. I just ran tests for StatsBase, Distributions, DataFrames, and several other key packages (on a recent 1.1 development branch) and they all passed. If this is indicative of the general state, then this is not a big problem for users. If a new user is adventurous, and wants to try packages immediately, and runs into a problem, it can be fixed by filing an issue (as suggested clearly on the download page.) or asking on a forum. I read the landing page and download page carefully. Almost every new user will try 1.0. But, I think the current language there will give the best experience for largest number of users.

1 Like

There were multiple postings about IJulia; PyCall also prevents SymPy (and PyPlot at a certain point?) to work, and these are all packages I use regularly. In any case, at this rate, they all are going to be working in the next days…

I guess the answer is “No, it’s not !”. IJulia especially is very important.

It would have been even simpler to just wait a month to release 1.0. I think you guys got a little over-excited there. :laughing:

No worries though, I think the overall the state of things is quite good. In a month I’m sure everything will be very smooth and whatever frustrations or confusions there were will be forgotten. Julia 1.0 is a thing of beauty, thanks to everyone for all their hard work.

4 Likes

That is not true at all in my opinion. There were multiple upgradathon days spread out over many weeks and the interest was quite lackluster. And then when the thing actually releases, people start upgrading like crazy. It seems that the lesson here is to release Julia when Julia is ready to be released. The ecosystem will follow quickly.

20 Likes

Maybe some package maintainers were waiting until a RC was available, to avoid trying to fix issues against a moving target. In Python or Clojure, for example, you have at least two weeks (and in some cases over one month) between the first release candidate and the final release.

1 Like

Sure, and there was multiple 0.7 RCs.

v0.7.0-rc2 was announced on August 3 (rc1 had been released a couple of days before, but not announced): “It’s intended to give developers a chance to get ready for the full 0.7 release by trying it out and testing for issues.” The final v0.7.0 was announced on August 8, less than five days later.

v1.0.0-rc1 had been announced 12 hours before that, including similar language: “It’s intended to give developers a chance to get ready for the release of 1.0 by trying it out and testing for issues.” Developers had one day to get ready.

Even counting from the unnanounced v0.7.0-rc1 there was barely a week until the final release of v1.0.0. It’s not exactly comparable to other languages, where you get a couple of weeks for minor releases and substantially more when the changes are important (as 0.7/1.0 clearly was in the case of Julia).

Edit: it’s done now, which of course the important thing, and the only harm is a bit of confusion until the situation settles down. The problem is not that it was fast but that it was unexpectedly fast, even by Julia standards (I’ve noticed now that previous releases also had a 4-6 weeks RC period).

1 Like

It was a bit fast but sometimes you just have to stick with a deadline. It’s done now.

8 Likes

Yeah you are right. I got the betas vs RCs mixed up I think.

1 Like