# Dropping support for 0.5 on JuliaBox

**URL:** <https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390>\
**Category:** Community\
**Tags:** juliabox\
**Created:** [January 15, 2018, 8:51pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390 "2018-01-15T20:51:50Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![avik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/avik/32/17_2.png) [@avik](https://discourse.julialang.org/u/avik)\
**Post date:** [January 15, 2018, 8:51pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/1 "2018-01-15T20:51:50Z")

</div>

We are considering dropping support for Julia v0.5 in Juliabox in a few weeks time. 0.7 support will added some time later, probably once a beta is released. But for the moment, dropping 0.5 support will enable us to better support 0.6 for all users.

So this message is really to solicit feedback – is there anybody out there who absolutely must have 0.5 supported on juliabox? If so, we would like to understand your use case, and whether you would consider migrating to 0.6 in the next few weeks. Let us know on this thread, or privately on [juliabox@juliacomputing.com](mailto:juliabox@juliacomputing.com) if you prefer.

Regards

Avik

---

<div class="post-metadata">

**Author:** ![anon61610682](https://avatars.discourse-cdn.com/v4/letter/a/ad7895/32.png) [@anon61610682](https://discourse.julialang.org/u/anon61610682)\
**Post date:** [January 16, 2018, 8:58am UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/2 "2018-01-16T08:58:58Z")

</div>

Just a small comment. I personally believe that the momentum is very big when it comes to dropping support. I have tried maintaining packages myself as well as contributing to some packages, even though they might not be as actively used as the usual suspects such as the differential equations family.

When a package has dependencies on others, whose maintainers choose to drop support for previous versions as opposed to using `Compat` as much as possible, it gets tough to maintain a package.

Basically, I would like to ask whether such a momentum is intended, or will it calm down a bit once `v0.7` (or, `v1.0` for that regard) is released?

That being said, I have already removed my `v0.5` installation locally, and I would be preparing my (small) packages for `v0.7` soon. Asking just out of curiosity.

---

<div class="post-metadata">

**Author:** ![avik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/avik/32/17_2.png) [@avik](https://discourse.julialang.org/u/avik)\
**Post date:** [January 16, 2018, 10:01am UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/3 "2018-01-16T10:01:25Z")

</div>

I think that the churn in the packages is high now and for the next few months due to 0.7/1.0. This disruption is greater than the transitions between previous releases. However, the reason we are going through it is that we expect very high stability going forwards. When 1.0 is released, we hope to keep further releases backwards compatible for a reasonably long time. So yes, I do think things will calm down once 1.0 is released.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [January 16, 2018, 12:10pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/4 "2018-01-16T12:10:53Z")

</div>

> [@aytekinar](#):
>
> Basically, I would like to ask whether such a momentum is intended, or will it calm down a bit once v0.7 (or, v1.0 for that regard) is released?

Changes between v0.5 and v0.6 are meant to be breaking, as in, code from v0.5 will break in v0.6. This makes it hard to maintain the difference, and with so few people stay back it’s hard to justify working on something that’s older. The difference between v1.0 and v1.1 by definition is supposed to not be breaking, so most code should work on both, except if they use new features then they need to be disabled on previous versions. That’s much easier to maintain, and with the stability of v1.0 syntax is something to actually aim for.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 16, 2018, 12:20pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/5 "2018-01-16T12:20:49Z")

</div>

> [@aytekinar](#):
>
> When a package has dependencies on others, whose maintainers choose to drop support for previous versions as opposed to using `Compat` as much as possible, it gets tough to maintain a package.

There is a trade-off here: most packages are maintained by volunteers in their own time, which is a finite resource: when you spend more time on maintaining compatibility, you can spend less on other things, like improvements, bugfixes, or just adding more tests.

Even if it is a matter of just adding `Compat`, one still has to run the tests for multiple versions, be ready to deal with issues for previous versions, or just postpone refactoring which is incompatible with them, etc.

Maintaining compatibility for a narrow range of versions can of course lead to upgrade deadlocks, which should be avoided. IMO providing support for the previous release for, say, 3-6 months is kind of a sweet spot. Also, even when the language stabilizes, packages can be expected to move at a faster pace as the ecosystem matures. I expect (hope) that we will see major version increases in important packages very frequently for years after `v1.0`.

---

<div class="post-metadata">

**Author:** ![anon61610682](https://avatars.discourse-cdn.com/v4/letter/a/ad7895/32.png) [@anon61610682](https://discourse.julialang.org/u/anon61610682)\
**Post date:** [January 16, 2018, 1:57pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/6 "2018-01-16T13:57:15Z")

</div>

> [@ChrisRackauckas](#):
>
> Changes between v0.5 and v0.6 are meant to be breaking, as in, code from v0.5 will break in v0.6. This makes it hard to maintain the difference, and with so few people stay back it’s hard to justify working on something that’s older. The difference between v1.0 and v1.1 by definition is supposed to not be breaking, so most code should work on both,

I can understand it from the semantic versioning. However, still, I think that the momentum has been huge.

> [@ChrisRackauckas](#):
>
> That’s much easier to maintain, and with the stability of v1.0 syntax is something to actually aim for.

Well, the last sentence is what I hope to see 🙂

> [@Tamas\_Papp](#):
>
> There is a trade-off here: most packages are maintained by volunteers in their own time, which is a finite resource: when you spend more time on maintaining compatibility, you can spend less on other things, like improvements, bugfixes, or just adding more tests.
> 
> Even if it is a matter of just adding Compat, one still has to run the tests for multiple versions, be ready to deal with issues for previous versions, or just postpone refactoring which is incompatible with them, etc.
> 
> Maintaining compatibility for a narrow range of versions can of course lead to upgrade deadlocks, which should be avoided. IMO providing support for the previous release for, say, 3-6 months is kind of a sweet spot. Also, even when the language stabilizes, packages can be expected to move at a faster pace as the ecosystem matures. I expect (hope) that we will see major version increases in important packages very frequently for years after v1.0.

I do not agree with you. I might be the only one to think along these lines, but still, as I said above, I just find it too aggressive. We have `Compat` for this purpose, right? As a package maintainer, you always update your package for the most recent language syntax and add `@compat` in front of such modifications to support backward compatibility. This, in my opinion, is easier than bumping the version of the minimum required `julia` version in `REQUIRE`. There are successful packages such as [KNet.jl](https://github.com/denizyuret/KNet.jl) which defer the [version bumping](https://github.com/denizyuret/Knet.jl/blob/v0.8.5/REQUIRE) of julia as much as possible. When you keep bumping the minimum julia version required in a package, _and do not propogate bugfixes in previous releases of a package_ (which is what I have experienced before), then the user and/or dependent package maintainers need to choose between backward compatibility and bugfixes. Anyways, this is not directly the problem of the language’s momentum per se, but I needed to bring it up here due to the comments I received from both of you, guys.

I am happy to hear from @avik, thoguh, that the expectation (at least from his perspective) is to have a slower pace.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [January 16, 2018, 2:04pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/7 "2018-01-16T14:04:21Z")

</div>

> [@aytekinar](#):
>
> As a package maintainer, you always update your package for the most recent language syntax and add @compat in front of such modifications to support backward compatibility.

No you can’t if one of your dependencies does a breaking change and updates the minimum version, unless you `@static if` to support both. It gets complicated really fast.

---

<div class="post-metadata">

**Author:** ![ssfrr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ssfrr/32/3736_2.png) [@ssfrr](https://discourse.julialang.org/u/ssfrr)\
**Post date:** [January 16, 2018, 2:09pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/8 "2018-01-16T14:09:01Z")

</div>

> [@aytekinar](#):
>
> As a package maintainer, you always update your package for the most recent language syntax and add @compat in front of such modifications to support backward compatibility. This, in my opinion, is easier than bumping the version of the minimum required julia version in REQUIRE.

I can tell you from experience that while Compat makes it much easier to support multiple Julia versions than it would be without it, there are still cases where it’s simpler to just drop support for older versions.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [January 16, 2018, 2:15pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/9 "2018-01-16T14:15:00Z")

</div>

> [@ssfrr](#):
>
> I can tell you from experience that while Compat makes it much easier to support multiple Julia versions than it would be without it, there are still cases where it’s simpler to just drop support for older versions.

Not to mention some cases where Compat introduces a breaking change, like how it became incompatible with finalizers and broke Sundials.jl for a day, so I just removed v0.5 support and Compat.jl as a quick fix since I couldn’t find out how else to handle (other than maybe a `@static if`)

---

<div class="post-metadata">

**Author:** ![anon61610682](https://avatars.discourse-cdn.com/v4/letter/a/ad7895/32.png) [@anon61610682](https://discourse.julialang.org/u/anon61610682)\
**Post date:** [January 16, 2018, 2:16pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/10 "2018-01-16T14:16:27Z")

</div>

I agree with you all. _Personally_, I do think that the momentum in julia and things getting agressively fast and more efficient are cool. However, again from my _personal_ experience, such a momentum results in incompatibility problems. For my personal computing needs, I use a bleeding-edge linux distribution whose package manager simply gives me the latest versions of packages from day 0. But then, there are other distributions where the package manager provided julia dates back to `0.4.7`. This applies to some virtual machines in the cloud, too.

Anyways, sorry for bringing up the issue. Apparently, it is only me who has problems with the momentum when trying to introduce julia and its packages to some group of people.

---

<div class="post-metadata">

**Author:** ![ssfrr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ssfrr/32/3736_2.png) [@ssfrr](https://discourse.julialang.org/u/ssfrr)\
**Post date:** [January 16, 2018, 2:28pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/11 "2018-01-16T14:28:13Z")

</div>

it’s definitely not only you, and I didn’t mean to discount your experience. It can be frustrating when things break out from under you. From a package maintainers perspective though, Compat isn’t always the silver bullet it may first appear to be, and given how fast Julia is moving a lot of folks (myself included) make the judgement call that it’s not worth spending the extra time keeping things working on older versions, and would rather focus energy on getting ready for 0.7 and adding new features and bugfixes. Hopefully as the pace of breakage in Julia slows down, users will see more stability in the package ecosystem as well.

As a side note, I do think it’s a shame that system package repos are providing unsupported Julia versions. It seems like it might be better to just not provide a julia package rather than providing one that’s that out-of-date.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 16, 2018, 3:23pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/12 "2018-01-16T15:23:34Z")

</div>

> [@aytekinar](#):
>
> there are other distributions where the package manager provided julia dates back to `0.4.7`.

There is no excuse for this. Installing the binaries from the tarball is trivially easy.

I can understand that a person or a team may be in a production situation where they want to freeze the world for a while. This is reasonable. But it may not be practical to expect to get the benefits of the developer’s work at the same time. The right approach is to dive in an port to the next version ASAP.

The benefit of making your code public is of course that if you have users who really want your package to work, then you get a PR 😄 In my experience, minor compatibility cleanup PRs that pass the unit tests are well-received.

---

<div class="post-metadata">

**Author:** ![johansigfrids](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johansigfrids/32/3590_2.png) [@johansigfrids](https://discourse.julialang.org/u/johansigfrids)\
**Post date:** [January 16, 2018, 8:40pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/13 "2018-01-16T20:40:36Z")

</div>

Which version of Julia are they using for the Julia Programming course that just started on Coursera? I would assume most students will use JuliaBox, and it could be awkward if the code for the course was written for Julia 0.5 if support for 0.5 disappeared just as the course got going.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [January 16, 2018, 8:50pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/14 "2018-01-16T20:50:28Z")

</div>

> [@johansigfrids](#):
>
> Which version of Julia are they using for the Julia Programming course that just started on Coursera? I would assume most students will use JuliaBox, and it could be awkward if the code for the course was written for Julia 0.5 if support for 0.5 disappeared just as the course got going.

Julia v0.5 is disappearing. It would be awkward to teach it. Nobody should be bringing new people on board there.

---

<div class="post-metadata">

**Author:** ![johansigfrids](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johansigfrids/32/3590_2.png) [@johansigfrids](https://discourse.julialang.org/u/johansigfrids)\
**Post date:** [January 16, 2018, 8:55pm UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/15 "2018-01-16T20:55:52Z")

</div>

Sure, in principle I agree with you. I just don’t know how much ahead of time the material for the Coursera MOOC was created. There is a risk that some of it is old.

EDIT: Of course, if the code was written for 0.5 it should work on 0.6, just with deprecation warnings.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 17, 2018, 7:25am UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/16 "2018-01-17T07:25:20Z")

</div>

Using something with `v0.*` version numbers implies that you need to update the course materials a couple of times a year, or it will go out of date.

If course materials based on `v0.5` (or, heaven forbid, earlier versions) are left unchanged, the major problem is not that the code will not run. That is actually _beneficial_. Somehow getting it to run and teaching outdated semantics is actually much worse: it is a disservice to the students.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [January 17, 2018, 9:31am UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/17 "2018-01-17T09:31:17Z")

</div>

> [@Tamas\_Papp](#):
>
> > [@aytekinar](#):
> >
> > there are other distributions where the package manager provided julia dates back to 0.4.7.
> 
> There is no excuse for this.

There are legal excuses in Debian: [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832798](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832798)

---

<div class="post-metadata">

**Author:** ![anon61610682](https://avatars.discourse-cdn.com/v4/letter/a/ad7895/32.png) [@anon61610682](https://discourse.julialang.org/u/anon61610682)\
**Post date:** [January 17, 2018, 9:47am UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/18 "2018-01-17T09:47:19Z")

</div>

Well, there might be other excuses such as

1. installing `julia` from source, which takes time as in any installation procedure,
2. the use case (and hence, installation procedure) might include some virtual machines in the cloud (not necessarily a `docker` image obtained from the official `julia` repo at Docker Hub (internet fees and time charges apply)),
3. parallel computations among worker nodes in the cloud, which _need_ to match the _exact_ version of the master machine used (here, people always refer to the semantic versioning above, and claim anything like `v0.*` implies materials need to be changed. However, in this situation, anything in the patch level, _i.e._, `0.x.*` is not compatible when it comes to distributed programming, either)

Situations like the above simply complicate things when it comes to me using `julia`, especially when I need to agree with people on some version. Again, this is not a problem when it comes to me using my machine at my will. But there _are_ situations that dictate certain constraints. However, no matter what I try to say, there will _always_ be responses along the lines “well, there are no excuses. fix it.”

Anyways, I am happy to see the response from avik, who (at least from his own perspective) expects to see a slower pace later on.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 17, 2018, 10:14am UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/19 "2018-01-17T10:14:47Z")

</div>

> [@giordano](#):
>
> There are legal excuses in Debian

This may be valid from their POV, but there is no law that says that you cannot install from a tarball.

> [@aytekinar](#):
>
> installing `julia` from source, which takes time as in any installation procedure

But why would you, if you have binary images available? Also, even if you insist on doing it, it is something that happens relatively infrequently (months pass between releases). Regarding the cloud etc, you have to assume that someone with at least minimal skills is running it, and can manage a simple upgrade.

We could go on about this indefinitely—excuses are really easy to make up. The bottom line is that until you have a stable release, you cannot expect the world to stop moving for your sake.

---

<div class="post-metadata">

**Author:** ![anon61610682](https://avatars.discourse-cdn.com/v4/letter/a/ad7895/32.png) [@anon61610682](https://discourse.julialang.org/u/anon61610682)\
**Post date:** [January 17, 2018, 10:17am UTC](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390/20 "2018-01-17T10:17:38Z")

</div>

Yes, you are definitely right. My bad…

[Next page](https://discourse.julialang.org/t/dropping-support-for-0-5-on-juliabox/8390.md?page=2)