fix Julia 1.6

[SimonDanisch]

When I look at the CI jobs on the last commit on main it looks like Arrow tests aren't run against 1.6, but the CI.yml looks like it does consider 1.6 - but it's also a more complex setup, I guess something may go wrong somewhere?
Anyways, the latest tagged version of Arrow.jl fails to compile on Julia 1.6...

[bkamins]

@quinnj - is this line

arrow-julia/.github/workflows/ci.yml

Line 86 in b49255a

version: '1.6'

disabling Arrow.jl tests on Julia 1.6?

[bkamins]

The reason for error is that @lock is not exported in Julia 1.6. Its export was added in JuliaLang/julia#39588

[ericphanson]

Looking at the git history, I think those exclusions were originally intended so that ArrowTypes and Arrow could have different minimum supported Julia versions (xref #223), but were incorrectly updated over time, such that now they incorrectly exclude things.

[ericphanson]

Can you remove those exclusions from the workflow and bump the patch version @SimonDanisch? Then we can see CI passing on 1.6 here and merge

[quinnj]

Oof, yeah, sorry about the mixup here folks.

[ericphanson]

cc @kou apparently Arrow.jl v2.4 is totally broken on Julia 1.6 and won't even load, causing CI issues in a lot of places (particularly private repos at Beacon where we use a lot of Arrow.jl). Can we either:

• expedite the patch release faster than 24 hr, OR
• register this in the Julia package registry before the official release vote goes through?

[ericphanson]

cc @kou apparently Arrow.jl v2.4 is totally broken on Julia 1.6 and won't even load, causing CI issues in a lot of places (particularly private repos at Beacon where we use a lot of Arrow.jl). Can we either:

• expedite the patch release faster than 24 hr, OR
• register this in the Julia package registry before the official release vote goes through?

Actually, we can just yank the 2.4.0 release, meaning it won't be installed by default anymore. This will solve the CI issues. Then we can land 2.4.1, waiting the 24 hours.

[ericphanson]

Ok, 2.4.0 is yanked on the General registry, so at least we don't have the broken release causing CI problems. Now we can re-land the release as 2.4.1.

[bkamins]

We might want to wait with the release for #350 to be merged (that PR is small, but requires a review from someone who has good understanding of different requirements of host platforms)

[bkamins]

(but if that PR is problematic I would not wait with the release)

[ericphanson]

I tried making a 2.4.1-rc1 but I don't have java installed, nor a PGP key, and I am out of motivation for today. So waiting sounds fine to me. It sounds like @baumgold needs the features in 2.4 though.

[baumgold]

It seems we're still not able to make a 2.4 release? I lost track of what the holdup is at this point...

[ericphanson]

Someone needs to do the steps from https://github.com/apache/arrow-julia/tree/main/dev/release#release

[kou]

1. Test the revision to be released

Could you confirm that the current main is releasable?

2. Increment version number in Project.toml

Could someone open a pull request for it?

Then, I can do the following tasks:

3. Prepare RC and vote (detailed later)
4. Publish (detailed later)

If there is a person who wants to try these tasks, I can support the person.

[ericphanson]

This PR incremented the version number, in anticipation of a release. Is it better next time if that is a separate PR?

[kou]

Oh, I didn't notice it.
I think that a separate PR is better because we need to choose which version (major/minor/patch) to be incremented when we put multiple changes to one release.
But we can choose this mixed approach by discussing and reaching a consensus. It's for "Open Communications" in the Apache way. If it's needed, we should open a new issue for it.

Could you confirm that the current main doesn't include a backward compatibility change nor a new feature? (I think that this project follows semantic versioning, right?)

[ericphanson]

this project follows semantic versioning

Yep!

confirm that the current main doesn't include a backward compatibility change nor a new feature?

Since v2.4.0 we have

• this PR: bugfix
• fix BatchIterator iterate method to handle partial messages #356: bugfix
• replace custom debug handling with LoggingExtras #355: internal tooling change / not really sure if it's a bugfix or feature
• Ensure Julia types have alignment respected #357: bugfix
• allow append to act on non-existent/blank file/io #358: not sure, bugfix or feature

Maybe someone else can weigh in about #355 and #358

[quinnj]

All bugfixes; a patch release should be appropriate

[kou]

OK. I'll prepare RC and vote.

[kou]

Vote thread: https://lists.apache.org/thread/mp8mg70c01kvs4648ttq1kq4vq9nr7cv

[kou]

Passed: https://lists.apache.org/thread/q9bjmktlowkj5xm93nsw5cpjh2kgmjtf

Could someone update the Julia General registry?

[ericphanson]

Ok, I've made JuliaRegistries/General#72443 to register 2.4.1. When that PR is merged, it will be registered in General

edit: merged