Drop support for Julia prior to v1.6

[martinholters]

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).

[codecov[bot]]

Codecov Report

Merging #767 (3d33d9a) into master (3ae185f) will increase coverage by 9.21%. The diff coverage is 100.00%.

@@            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     

Impacted Files	Coverage Δ
src/compatmacro.jl	85.71% <ø> (-2.53%)	:arrow_down:
src/Compat.jl	88.80% <100.00%> (+9.76%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 3ae185f...3d33d9a. Read the comment docs.

[martinholters]

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?

[KristofferC]

Makes sense to me to do this.

[simeonschaub]

Sure, go ahead!

[KristofferC]

I added a revert commit for this to the General registry (https://github.com/JuliaRegistries/General/pull/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

[martinholters]

I think it is (technically) breaking because it drops previously deprecated functionality. I doubt it breaks anything in practice, though.

[nalimilan]

OK. Could we keep the deprecations or are they too heavy for that?

[martinholters]

Getting rid of those is what brought us here (ref #765).

[bkamins]

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.

[martinholters]

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?

[KristofferC]

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.

[bkamins]

You make sure it works with Compat v4.0

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.

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.

This is what I also understand.

The question is that if I make e.g. https://github.com/JuliaLang/Compat.jl/pull/770 so that it can be merged to master who will then can make a backport to 3.x branch and releases of both 4.x and 3.x versions?

[martinholters]

My proposal would be: One of the maintainers (e.g. me) forks off a release-3 branch, and then anyone who needs a backport of something (e.g. you) opens a PR against that branch. As usual, one of the mantainers then fires off tagging a release. How does that sound?

[bkamins]

How does that sound?

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?

[KristofferC]

So what do people think? Is a breaking version best after all?

[bkamins]

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.

[mcabbott]

During Compat 2 -> 3, one issue was some abandoned packages holding things back, e.g. https://github.com/JuliaRegistries/General/pull/11257 . Have not tried to figure out whether there are any such now.

[bkamins]

During Compat 2 -> 3, one issue was some abandoned packages holding things back

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.

[martinholters]

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 :wink:. 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 Project.toml.

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.

[mcabbott]

If you do decide to add new things to both 3.x and 4.x branches, can these have matching numbers? Thus start at 4.43.0 or whatever.

[martinholters]

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.

[nalimilan]

Tagging 4.0 looks OK then. Sorry for the noise, I hadn't realized that dropping old heavy features required being breaking.

[bkamins]

I'd prefer only backporting things when and if there is demand.

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).

[martinholters]

Ok, I've created a release-3 branch. If we want to set up some branch protection rules - and I'd say we do - someone else has to do it, I don't have sufficient privileges.

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?

[davidanthoff]

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?

[bkamins]

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

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.

[bkamins]

@martinholters - I think also https://github.com/JuliaLang/Compat.jl/pull/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)

[oxinabox]

Looking at the issues I can't see a motivating reason for dropping Julia 1.0 support. (And thus a breaking change). Apologies if I missed it.

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)

[JeffBezanson]

Is it some how linked to cutting down on dependencies on stdlibs?

Yes. Without this, lots of applications need to pull in every stdlib even though they aren't used.

[martinholters]

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?

You have to convince them to keep supporting Julia 1.0. Then they can't drop Compat 3 compatibility anyway.

[martinholters]

I think also https://github.com/JuliaLang/Compat.jl/pull/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)

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?

[bkamins]

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:

• 3.x branch supports Julia back to 1.0 and 4.x supports only 1.6 and newer releases of Julia.
• Packages that want to support Julia back to 1.0 are recommended to allow Compat.jl both 4.x and 3.x in their Project.toml (so that they can work with packages that allow only 4.x release under Julia 1.6 or newer)
• maybe there are some other aspects to note I am not aware of?