Julia Package: different branches for different Julia-versions?

package

#1

I’m the owner of the ODEInterface package and I have the following question. At the moment I’ve written the code in such a way, that it runs under julia v0.4, v0.5 and v0.6 without any warnings. Because of the changes in the julia syntax in the nightly versions (struct, etc.) I plan to do a cut.

Is it possible to have different branches in my github-repo for different julia versions (e.g. one for older julia-versions and one for the current stable)? If this is possible, how do I have to enter this in the METADATA files? Must the content of sha1 be a commit-hash in the master branch?

I’ve seen that it is possible to increase the julia version number in the REQUIRE file. But then it seems to me (perhaps I’m wrong), the older versions of the package are some kind of “fixed”: What if I want to do bugfixes for the versions of my package that are for the older julia versions as well as for the version of my package for the current stable julia version?

I hope this is the/a right place to ask this kind of question.

Thanks
C. Ludwig


#2

Just use different branches. You can tag from non-master branches, so it’s common to have a “v0.5-backports” branch just for this. But also, I wouldn’t spend too much time with version compatibility since almost all of the community stays updated, and when they don’t there are other issues. So I would only do this if it doesn’t take much effort.

Thanks for ODEInterface BTW. It’s a great package and I love having those classic codes easily available in Julia!


#3

Thank you for your fast answer.

Then I’ll try a backports-branch in my next “programming/update” cycle.

Thanks for ODEInterface BTW. It’s a great package and I love having those classic codes easily available in Julia!

Thanks. We are still looking for persons who want to implement this solvers in 100% pure julia (in order to solve ODEs with other datatypes than Float64, e.g. bigfloats, complex numbers, dual numbers, etc.)


#4

Well, that already exists :smile:.

Most of these solvers are implemented in pure Julia. DifferentialEquations.jl’s (well, OrdinaryDiffEq.jl’s) DP5 and DP8 match the stepping behavior of dopri5 and dop853 (there’s tests in the repo which confirm that on example problems they hit the same times and the same values). rodas has a native Julia implementation as of yesterday and the timestepping behavior is much much better optimized for the tolerances which it’s normally used (and it gets to use ForwardDiff!). These improve the efficiency over the Fortran versions, are compatible with arbitrary arrays and number types (tested with bigfloats, complex numbers, dual numbers, arbfloats, units, etc.), have event handling implemented on them, etc.

From my tests odex and seulex are not very competitive so they are further down the list. But the next goals are implicit RK methods (radau) and then multistep methods.

Check out the release notes for today’s DiffEq ecosystem release for more on the newest Rosenbrock additions.

And see DiffEqBenchmarks.jl for benchmarks of the native Julia RK methods vs the Hairer Fortran methods (through your wonderful wrapper!)