I’m wondering how to approach the job of moving a package from supporting Julia v0.6 to v0.7. My current thinking is like this:
1 - make a release for Julia v0.6 ()
2 - create a git branch v07changes
3 - make v0.7 changes (e.g. deprecations, new syntax, Sys.isunix…, etc)
4 - remove support for earlier versions (e.g. older Compat statements, BaseTestNext, broadcast (#17623), …)
5 - change the REQUIRE file to say julia 0.7-
6 - test and merge branch to master
7 - make a v0.7-only release using Attobot
8 - keep the v0.7-only version up to date with all the forthcoming breakages etc…
9 - don’t touch v0.6 version again…
Is this how you do it? Perhaps there’s a guide somewhere — I’m not well-versed in this side of package development.
(I’m assuming v0.7 is next — although it’s not a milestone… ?
Your plan is good … v0.7 is next and it will provide the deprecations and additions and amendations bridge to v1.0. The intent is that packages which work cleanly under v0.7 (no warnings or other bothers) should expect that holds for v1.0.
It has been common practice to let go of intent support for pre-1.0 versions that have seen two 0._.0 steps since their introduction. This is not true for e.g. the NY FED who uses v0.4.x (afaik) as that is the version in which their major development work happened and for which they had some dedicated highly-skilled help. There is nothing in your plan that is counterproductive, and much that moves your work forward version-wise.
Why would you need Compat if you change the minimum version to 0.7? On Plots so far we make a final 0.6 release that works, and branch a backports-0.6-branch off from that. We then up the minimum version number to 0.7 and merge the 0.7 branch into master. All new features only happen on master and thus only come to the people using 0.7, whereas fixes for annoying bugs can be backported to the 0.6 branch, and releases targeting 0.6 users can be made off from that.
It’s also possible to write packages that support both 0.6 and 0.7 without much hassle, so I wouldnt rush to completely deprecate v0.6 yet, since in v0.7 you can still have warnings. Therefore, I would first upgdate to v0.7 with warnings and compatibility with 0.6, then tag, and then deprecate 0.6 in the next tag. This way you can still address bugs for 0.6 users before completely moving to 1.0
I am new to the package system of 0.7, and I have a package working for 0.6. I already made the changes that make it compatible with 0.7 and solve deprecation warnings on a separate branch. How do I then release the package for 0.7 so that on v0.6 Pkg.add will still download the right version?
On your 0.7 branch, make sure your REQUIRE file says julia 0.7-. Then tag a release from that branch (increase your minor version, not just your patch version), and if you have set up attobot, it will create a release for you.
Can you explain the syntax of julia 0.7-. I thought it means it works for everything below 0.7 which doesn’t make sense here At least I used julia 0.6 0.7- to express 0.6-0.7 without including 0.7 as I know my package breaks for 0.7.
)
At least I used