PSA: use Julia 0.7 if you are upgrading

psa

#1

A lot of people are posting issues where their old code doesn’t work anymore on 1.0 because some function has been renamed or removed. The 0.7 release exists exactly for this reason: your old code will work on 0.7 and give you a specific warning about how to fix your code. If you have any old code, you should use 0.7 to get these warnings before switching to 1.0; even if you just have work habits that may need changing, you should probably use 0.7 for a while.

If someone posts an issue like this in discourse, feel free to just link them to this post.

PSA = Public Service Announcement


error in read data in JULIA v1.0
Julia 1.0 add JLD Error
failed to build packages on linux under julia v1.0.0
Replacement of eigs?
#2

#3

Stef,

Of course, there are problems with 1.0, fortunately there still is some work to do!

Before Julia, there was no problem with Julia…! But was it better?

There are always more problems with the future than with the past, and Julia is made for the future!

What you have done is not perfect, but it is wonderful!

T.


#4

A post was split to a new topic: New Pkg confusion


#5

I would tend to say that almost no one should use 1.0 day-to-day for the next month or so, until most packages have fully upgraded.

There is zero advantage to using 1.0 over 0.7 right now (except for testing), just more non-functioning packages, because 1.0 is just 0.7 minus deprecations.


#6

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 ¯\_(ツ)_/¯


#7

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


#8

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.


#9

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


#10

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?


#11

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.


#12

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.


#13

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?


#14

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?


#15

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


#16

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.


#17

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…


#18

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


#19

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.


#20

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.