Skip version 0.5


#1

I am using Julia version 0.4.7 and wish to upgrade to 0.6 in due time.
Is it possible to skip version 0.5, or I will miss important deprecation warnings?


#2

v0.5 compatibility is almost v0.6 compatibility. I think it’s easier to just transition to v0.5 compatibility first.


#3

Thanks.

v0.5 compatibility is almost v0.6 compatibility.

This hints that the single-step upgrade is in fact possible.

I think it’s easier to just transition to v0.5 compatibility first.

This suggests to choose the two-step upgrade.

It is still unclear to me if I will miss important deprecation warnings
if I choose the 0.4.7–>0.6 single-step upgrade.


#4

As far I as know, you will miss warnings because the typical Julia development rule is that one version issues deprecations and the next version removes the deprecated feature completely. So you’ll get errors instead of warnings.

It’s your call whether you want errors or warnings.


#5

Thanks for the clarification.

As I will have to change my code anyway,
maybe the error messages will be clear enough to do this.


#6

The problem is that there might be cases where you get neither errors or warnings, but rather silently get different results.
Consider how String was an abstract type in v0.3, was deprecated in v0.4, and is a concrete type in v0.5.
Skipping directly from v0.3 to v0.5 would make people miss places where they should have changed String to AbstractString, and then things might break further down the road if for example if they get passed a SubString instead of String.


#7

Thank you for the warning.
Do you know similar dangers going from 0.4.7 to 0.6 ?


#8

There are only downsides switching directly from 0.4x to 0.6. We recommend you not to do this. There will be very rare experience in such a transition so you will be quite alone when you don’t want to go the recommended route.


#9

We are currently doing the transition from v0.4.7 to v0.5 (but at the same time, testing on v0.6 master, so that hopefully, whatever changes we make, will only have to be done once), but I haven’t run into such yet (but I’m sure some are lurking there!)
Simultaneously testing on both (and accepting that v0.6 is a moving target) I think would be the best bet, if you want to switch to v0.6 as soon as possible after it is released.


#10

message taken:
the one-step upgrade from 0.4.7 to 0.6 is not recommended


#11

Good to know that the upgrade from 0.4.7 to 0.5.0 is worth the investment,
and the next upgrade from 0.5.0 to 0.6 will not be the same amount of work.

Last remark:
I was somewhat reluctant to switch to 0.5.0
because I was waiting for 0.5.x maintenance upgrades.
Of course this is not a complaint, just a turtle’s attitude.


#12
  • Currently nobody can predict how much effort it will be to switch from 0.5 to 0.6. Deprecations can be removed quite late in the release cycle.

  • That there were no maintenance upgrades during 0.5 does not mean anything. 0.5.0 is/was pretty stable, so no need to wait for 0.5.x releases.


#13

You should upgrade through 0.5 even if you’re upgrading to 0.6. In other words, run your code on 0.5 and get rid of all deprecation warnings and fix breakages. Then do the same for 0.6. This should not be all that difficult or take that long as long for the language itself. Packages are likely to cause more problems than language changes.


#14

Thanks.
Now I will definitely follow the 0.4.7->0.5.0->0.6.0 upgrade path.