Moving from v0.6 to v1.0 has been so annoying

General Usage
1

I just wanted to share my experience in moving from v0.6.4 to 1.0. I have to say, it has been extremely annoying, and I am wondering why I choose to work in Julia. The developers should have in mind there are several people out there who just want to use this language for scientific analysis, and it is not a good investment of their time if functions of common use are going to be removed/deprecated every now and then. Some examples of such functions are:

  1. linspace()
  2. find() … most disappointing for me, as it used it very often
  3. readstring()

and so on. I have to revise so much of my code now.

2

There’s been quite a few topics on this over the past week, and to some degree I suppose that’s unavoidable when putting out a major release with (by definition) breaking changes.

Just thought I’d throw in two pieces of info that you might well be aware of but if you aren’t might be helpful:

  1. If you have a large existing codebase that runs under 0.6, you might want to consider upgrading to 0.7 first before moving to 1.0 - that way you get helpful deprecation warnings rather than errors.
  2. Use FemtoCleaner to automate some of the process described in (1)

And if you’re interested it might be good to read up on the reasoning behind some of the changes that annoy you - generally there are pretty lengthy discussion here and/or on GitHub around these kinds of changes which give a good insight into the level of thinking that goes into them (no one is out there to annoy people who “just want to use the language”!)

13 Likes
3
8 Likes
4

My understanding of version 0.x software is that it’s considered unreliable and likely to change without notice:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

(From the semantic versioning site)

Perhaps that wasn’t communicated effectively to users who may be unfamiliar with software development methodology? I’d have to look at the old website to check.

2 Likes
5

I think you should state that more strongly: One should absolutely and unequivocally upgrade to 0.7 first, if one is updating a codebase. At least do it if you’re considering writing a frustrated post complaining about the upgrade process.

7 Likes
6

I am not sure what you would prefer. Languages change, usually for the better, do you want that not to happen? Only abandoned and dead languages keep their API forever.

While automated tools like FemtoCleaner can’t fix everything, I wonder if your frustration stems from not using them, since they made these trivial replacements mostly hassle-free.

1 Like
7

Thank you for this information. I wasn’t aware of how important it would be to upgrade to 0.7 before moving to 1.0, or to use FemtoCleaner either.

Sure, I’ll like to read them, but I’m more of a Julia user than developer. Thanks for responding though.

8

Thanks for sharing this post.

9

Even though some of these changes are frustrating as a user, if you try to put yourself in the language designer shoes, you’ll find they usually are the right choice (or at least an improvement over the previous situation). And if you search a bit on the forum or github, you often find explanations.

1 Like
10

It’s good that you have asked/complained! I have read and think that it probably would have been better to name 0.7 as 1.0 and ‘our 1.0’ as 1.1.

Now it’s too late and really important to comunicate again and again to use 0.7 first when upgrading to 1.0 (or 1.0.1). Btw. you can mark the answer from Sukera as solution, it will then be displayed right at your initial question.

1 Like
11

That approach would not have been without its issues though. Experience has shown that people really hate to fix deprecation warnings. Somehow they’d much rather just live with pages and pages of red spewing all the time than spend an hour on fixing the warnings. Or they turn the warnings off entirely. And then they’d be angry when they upgraded to 1.1 and things broke… “Hey, I thought Julia 1.x wasn’t going to break anything!” I’m pretty sure there’s no winning this one. People are going to be annoyed no matter what. Might as well tear the bandaid off.

13 Likes
12

Wouldn’t it also mean giving up semantic versioning?

13

Debatable. But I would argue that the expectation of “not breaking working code” is that if your program worked previously without errors or warnings then when you upgrade it will continue to work without errors or warnings. Any program that had deprecations warnings does not satisfy the antecedent and so does not get the protection of semantic versioning.

2 Likes
14

I think one can generalize this: people will always deprioritize fixing something that is not explicitly broken.

I think that removing deprecations from 0.7 to 1.0 was the right decision. A bit of a delay between the two version would have been nice though, for those package authors who were willing to fix things for 0.7/1.0, just needed a bit of time.

9 Likes
15

I am not sure, whether removing the deprecations (and the warnings) was such a good step. I understand it, but for new users it is quite a problem.

I have been in a similar situation: I started a new project and used 1.0 for it, because there was no prior code I had to use. Ultimately, I want to only use 1.0. Unfortunately, I tried to use linspace, which obviously did not work. However, I could not find any documentation about deprecated commands and which alternatives to use. In the end, I had to use version 0.7 just to find out what to do about the linspace-command. This provided the answer to use range. No big deal, but it tooke me quite a while to figure that out.

Currently, the main problem for new users is that most of the tutorials and examples on the internet are still pre-0.7 code. Accordingly, also new users need to use 0.7, instead of 1.0, to remove deprecations from these examples themselves. This is not really intuitive to figure out and can easily frustrate potential new users.

I understand the need to deprecate code or change syntax at some point. But for me a combination of 0.7 and 1.0 behaviour would have been optimal:
I would have liked to have the deprecation warnings in version 1.0 as well. I don’t want deprecated code to be running in this version, just get the warnings/solutions that are provided by version 0.7. This way, I would immediately be able to transition to the new code, whithout having to always switch back to 0.7 just to get the deprecation warning. New users would also know what to do with their outdated tutorials and examples. Last, but not least, this step could also “force” long-term users to transition their code.

Just as an idea: The code-base for the warnings is obviously present in version 0.7. Wouldn’t it be possible to include the warnings in version 1.0.2? (Most likely not, but I don’t know how much work it would be or whether or not it would be possible at all.)

Furthermore, it would be really helpful to have a synoptical overview about deprecated code and the alternatives to use at a prominent position. I know that there is a list of deprecated commands somewhere out there, I just cannot find it any more (maybe somebody can post the link). And as far as I remember, the list did not include the new commands.

3 Likes
16

This is a valid concern, but there is a trade-off: the expectation is that people would bother less to remove deprecations if the code kept working otherwise.

This is problematic since deprecations check a global state (to show once), which is slow. If you check the forum activity around the time of transition, you will notice many discussions along the lines of “Q: My code is slow. A: Have you fixed deprecations?”

1 Like
17

Maybe instead of having them as deprecation warnings one could have them as “instructive” error message, e.g. instead of

ERROR: UndefVarError: linspace not defined

something like

ERROR: `linspace(start, stop, length::Integer)` has been removed, use `range(start, stop=stop, length=length)` instead.

Not sure how much this would be feasible but it would fix the problem of having people go between 0.7 and 1.0

3 Likes
18

That is exactly what 0.7 with --depwarn=error gives you:

julia> linspace(0.0,1.0,10)
ERROR: `linspace(start, stop, length::Integer)` is deprecated, use `range(start, stop=stop, length=length)` instead.
4 Likes
19

Yes, exactly. My suggestion was to use this as default in 1.0. Which is more informative than just

ERROR: UndefVarError: linspace not defined
2 Likes
20

@ric.cioffi This is exactly what I wanted to suggest.