Drop support for Julia prior to v1.6 #767
Conversation
martinholters
force-pushed
the
mh/require-julia-1.6
branch
from
097cd44 to
e49eca9
Compare
Codecov Report
@@ Coverage Diff @@
## master #767 +/- ##
==========================================
+ Coverage 79.14% 88.35% +9.21%
==========================================
Files 4 2 -2
Lines 676 146 -530
==========================================
- Hits 535 129 -406
+ Misses 141 17 -124
Continue to review full report at Codecov.
|
| - "1.6" | ||
| - "~1.7.0-0" | ||
| - "1.7" | ||
| - "~1.8.0-0" |
There was a problem hiding this comment.
Might want to use the latest nightly builds of 1.8 as well?
| - "~1.8.0-0" | |
| - "1.8-nightly" |
There was a problem hiding this comment.
AFAIU we would have to change 1.8-nightly to 1.8 once 1.8 is released while ~1.8.0-0 will keep working?
From https://github.com/julia-actions/setup-julia/blob/b69122e25a41dfa3fc1b74a4e8c21fd842fc57c7/README.md:
~1.3.0-0is a tilde version range that includes all pre-releases. It matches all versions≥ 1.3.0-and< 1.4.0.1.7-nightlywill install the latest nightly build for the upcoming 1.7 release. This version will only be available during certain phases of the Julia release cycle.
martinholters
force-pushed
the
mh/require-julia-1.6
branch
from
f91494c to
3d33d9a
Compare
|
Well, this has been sitting idle for a while without anyone objecting so I'm inclined to go ahead and merge this in a few days. Or has anyone (@KristofferC, as you proposed doing this originally) second thoughts? |
|
Makes sense to me to do this. |
|
Sure, go ahead! |
|
I added a revert commit for this to the General registry (JuliaRegistries/General#60317) based on a discussion in slack that this should perhaps not have been a major release since it (allegedly) isn't breaking anything and it would force 220 packages to update their Compat. So just out of caution before too many people start upping their compat, I think it is good to yank the release and discuss it. If we still want to make a breaking release we just up the version to 4.0.1. cc @nalimilan, @bkamins |
|
I think it is (technically) breaking because it drops previously deprecated functionality. I doubt it breaks anything in practice, though. |
|
OK. Could we keep the deprecations or are they too heavy for that? |
|
Getting rid of those is what brought us here (ref #765). |
|
For me the important thing is do decide on a solution that ensures that packages that support Julia back to 1.0 release (like DataFrames.jl) have a clear instruction how they should use Compat.jl and have cross-version compatibility. The point is that we use Compat.jl exactly to ensure backward compatibility of DataFrames.jl with older versions of Julia. |
|
You make sure it works with Compat v4.0 (which it most likely does), declare compatibility with it (ín addition to previous versions you're also compatible with), and that's it? |
|
People that want to add features that apply to pre 1.6 would have to do that to a separate branch where pre 1.6 releases (3.x) are made from. |
The point is that it is impossible to do this until upstream packages you depend on also do this before (thus it is likely to take some time since this is a cascading process). Of course in the long run this will be achieved.
This is what I also understand. The question is that if I make e.g. #770 so that it can be merged to |
Forgot to do this in #767 ``` julia /path/to/julia/doc/NEWS-update.jl README.md ```
|
My proposal would be: One of the maintainers (e.g. me) forks off a |
OK - maybe then in #771 you could add a note then that both 4.x and 3.x branches are maintained so that package developers know how to use Compat.jl? |
|
So what do people think? Is a breaking version best after all? |
|
I think if we keep maintaining both 3.x and 4.x what we have is acceptable. This will allow package maintainers to easily handle the transition period. |
|
During Compat 2 -> 3, one issue was some abandoned packages holding things back, e.g. JuliaRegistries/General#11257 . Have not tried to figure out whether there are any such now. |
Therefore I think it is crucial to maintain 3.x branch of Compat.jl until we can see in JuliaHub that the ecosystem has migrated to 4.x. |
|
Reverting just the breaking part (i.,e. reinstantiating the deprecations and some other minor things) and then calling the next version 3.x again IIUC will not be much help for DataFrames, as it will then not be able to utilize any future additions to Compat.jl and at the same time keep supporting Julia <1.6. And we couldn't even meaningfully do any releases with backported features but compatibility with Julia <1.6. So the only option seems to be to revert this wholesale. And I would not take that personally 😉. But eventually, we will have go with a breaking change like this one, and I don't see how postponing it will improve anything. So I'd prefer just going ahead now. If that means keeping another branch for 3.x around for a transition period, then so be it. One downside is more complicated compatibility requirements downstream: if a feature is added in 4.x and backported to 3.y, you need to figure out both versions and put them in your Given that we've withdrawn 4.0.0, we could probably merge #770 before tagging another release (should that then be 4.0.1 or 4.1.0?) so that there would not be a 4.x without it, but in the future, we would have to take care of two versions bounds, at least for the next few features to be added. |
|
If you do decide to add new things to both |
|
I don't know whether leaving such a version gap is ok. Also, that would commit us to backporting everything (for a while). I'd prefer only backporting things when and if there is demand. |
|
Tagging 4.0 looks OK then. Sorry for the noise, I hadn't realized that dropping old heavy features required being breaking. |
I think backporting on demand is enough. Most likely PRs to Compat.jl are a consequence that some package needs some functionality so the person that opens such a PR is most likely the one that will need it (so it is easy to determine the required versions both for 3.x and 4.x if needed). |
|
Ok, I've created a Next steps would be merging #770 and tagging. #770 is basically good to go, I just don't know whether it should become 4.0.1 or 4.1.0. It adds a feature compared to 4.0.0, but as that has been yanked, it might not matter? Then backport #770 and tag 3.44. Or are there any objections against this course of action? |
|
The VS Code extension is another piece that can't drop Julia 1.0 support for a long time. Would we then just have to try to convince all packages that we use in the extension to keep Compat 3 in their compat list, and then everything should work? |
I assume that in DataFrames.jl we will keep Compat.jl 3.x and 4.x in long term. I think it should not be a problem assuming proper maintenance. |
|
@martinholters - I think also #771 should be merged (with added information about 3.x and 4.x release policy - as I have suggested earlier - so that package maintainers know what to do) |
|
Looking at the issues I can't see a motivating reason for dropping Julia 1.0 support. (And thus a breaking change). Is it some how linked to cutting down on dependencies on stdlibs? Is it becoming too hard to immigrate new features on old Julia versions? I think we have enough smart people that what ever the reason is, we can work out a way to get the goal accomplished without a breaking change to Compat.jl. (E.g. For dependencies can use the Requires.jl trick maybe -- and it will actually be semver safe unlike most uses of that package) |
Yes. Without this, lots of applications need to pull in every stdlib even though they aren't used. |
You have to convince them to keep supporting Julia 1.0. Then they can't drop Compat 3 compatibility anyway. |
Forgot to do this in #767.
I've merged #771 as is because it targeted an orthogonal issue. Adding something about "3.x and 4.x release policy" should probably be done separately. But honestly, I'm not sure what to write there. Should I open a PR witih some draft so that we can start discussing? |
If you could please do so. I imagined we would write that:
|
Drop old deprecations, remove anything specific to versions older than 1.6, and add a few new deprecations as needed. This lets all old tests still pass.
Closes #764, #765 (replacing the latter).