Unbreak Julia 1.0

[timholy]

Version 0.4 got released claiming to support Julia 1.0
(the [compat] is julia = "1") but 1.0 was dropped from CI.
Unfortunately, not only doesn't the package run on
1.0, it doesn't even parse. This means that every package
that wants to update their AbstractTrees dependency might try this

[compat]
AbstractTrees = "0.3, 0.4"

and while this works fine on Julia 1.6, it breaks on Julia 1.0.
Had AbstractTrees 0.4 merely declared incompatibility
with Julia 1.0, the package manager would have
handled everything for us---it would install AbstractTrees 0.3.x
on Julia 1.0, and 0.4.x on 1.6 and higher.

Now we are a bit stuck. One option is to see if General
would accept a PR retrospectively making AbstractTrees
0.4 uninstallable on 1.0. The alternative is to provide
at least minimal support for 1.0. I've taken that route here,
but I'd be equally fine with the idea of making a PR to
General.

CC @ExpandingMan

[timholy]

Example: timholy/MethodAnalysis.jl#31

[ExpandingMan]

This is my fault, I forgot to change the compat bound.

Personally, I'd prefer to try making a PR to general to unbreak it, but I don't really know how that would work.

If we merge this instead, I can put in another PR afterward to revert the changes but with the correct compat bound (I really don't want to encourage anyone to try to write code compatible with pre-1.6, it seems rather absurd at this point).

[timholy]

It's a really easy mistake to make. I've started wondering if we should check for this in the General automerge step.

One of us could play with https://github.com/JuliaRegistries/RetroCap.jl. I will get to it if you don't (but I'm occupied for the next couple of hours).

[ExpandingMan]

I'd be in favor of making it so that general will not auto-merge for anything that claims to support any version prior to the latest LTS. To be blunt, it is very hard for me to care about what is happening on pre-1.6, it's not likely to be something that will ever go through my mind when making PR's.

[oscardssmith]

@timholy is this ready to merge (it looks good to me).

[ExpandingMan]

Can we remove 1.0 support in 0.4 or would we have to tag an 0.5?

[oscardssmith]

it's not a breaking change. The resolver will fix it.

[timholy]

Thanks for merging this. I'm fine with reverting this if someone makes a PR to general to make 0.4 uninstallable, but this seems like an easy fix for now.

@ExpandingMan, totally agreed with the idea that supporting 1.0 is not a productive use of time for most packages, although there may be some exceptions (e.g., maybe VS Code and a few others). So I'm not sure we could go with your favored solution, but at least checking that CI is enabled seems to make sense. For most packages, the only goal should be to avoid breaking things that once worked.