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 if you prefer.
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.
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.
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.
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 can understand it from the semantic versioning. However, still, I think that the momentum has been huge.
Well, the last sentence is what I hope to see
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 which defer the version bumping 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.
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.
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)
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.
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.
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.
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.
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.
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.
installing julia from source, which takes time as in any installation procedure,
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)),
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.
This may be valid from their POV, but there is no law that says that you cannot install from a tarball.
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.
In my experience, minor compatibility cleanup PRs that pass the unit tests are well-received.