Hello, could someone reference to some standard instructions on the suggested workflow to upgrade packages to 0.7, especially for those not too practical in git ?
Currently I have my packages in 0.6 and trying to remove the 0.7 warnings, but some of this would imply break compatibility with 0.6.
Currently I have only a “master” branch, but I guess the ideal would be to create a 0.6 branch to allow bugs correction and backports for 0.6 and do the new 0.7 stuff in master.
That sound reasonable? How to do it in git and / julia package framework ?
If you want to keep compatibility with 0.6 the typical way is to use Compat.jl GitHub - JuliaLang/Compat.jl: Compatibility across Julia versions which tries to allow you to write your code in 0.7 fashion, while still have it working on 0.6.
If you rather just focus on 0.7, you can just fix all deprecation warnings and tag a new release (at least a minor version bump so e.g. 0.5.2 → 0.6.0) that only supports 0.7. If you then need to make changes to 0.6, you branch from the place where you dropped 0.6 support and “backport” or make commits to that branch. You can then tag a new 0.6 release (0.5.3 using the versions in the example above) from that branch.
3 Likes
Wouldn’t it be better to first branch a 0.6 compatible version, and then work on the master branch? It might be easier to edit the 0.6 version later on if it’s already branched out?
You can always branch from a previous commit though.
You can 
Just joking, yea, you are of course correct, but it might be easier for beginners to deal with branches rather than commits. I’m speaking from my own (lack of) experience…
You can check this package:
There is a branch for julia 0.4-0.6 and master for 0.7 (and hopefully above)
Should we somehow control in REQUIRE file that versions for 0.6 are not compatible with 0.7?
Yes, by putting a minimum version of Julia as eg 0.7-beta2