Release DataFusion 56.0.0 (Oct/Nov 2026)

@Xuanwo

Is your feature request related to a problem or challenge?

Part of [EPIC] DataFusion Releases #19783

Previous release is #22393 (Jul / Aug 2026) so next major release would be approximately Sep / Oct 2026.

Steps:

Features to mention in the blog (if they make it)

Bugs/issues that should be fixed

Side effects from serde_json/preserve_order feature impact user applications #25883 @adriangb
[dbolympics] fix: cast outer projection expr to declared field type in SingleDistinctToGroupBy #26211 from @jayzhan211
Rename LogicalPlan::DescribeTable to LogicalPlan::Show move statement implementations out of sql module #26057 from @pepijnve (to reduce API churn)
refactor: register proto decoders with T::register_proto instead of a free function #26565 from @adriangb (so it is not a breaking change later)
feat: allow extension DataSources to decode via a per-type registry #26555 from @gabotechs (so the proto type-registry refactor from feat: allow extension ExecutionPlans to decode via a per-type registry instead of PhysicalExtensionCodec #24631 / feat: allow extension PhysicalExprs to decode via a per-type registry #24628 does not ship in an intermediate state)
DISTINCT ON with nested payloads can fail memory reservation after spilling #26744 from @shehabgamin

Community Wishlist

I can help with this release!

Really hope #318 can deliever in v56.0, let's rock!

318 -- perhaps the lowest issue number left open that tracks something useful. A long standing request

One more question: what testing needs to be done for releases? Perhaps we could also include lance. I'm willing to take on all the related work.

@Xuanwo

One more question: what testing needs to be done for releases? Perhaps we could also include lance. I'm willing to take on all the related work.

Thanks @Xuanwo -- I think what we typically do is to use the release ticket to coordinate testing with downstream crates that wish to help as we get close to making a release candidate. So for example, @AdamGS often tests with Vortex as part of that process.

Here is an example in the 55 release ticket where we were disucssing it

Release DataFusion 55.0.0 (Jul / Aug 2026) #22393 (comment)

Since this release will have an update to arrow/parquet to version 60, perhaps this would be a good candidate to try out "LTS" / Long term support: #16622

Since this release will have an update to arrow/parquet to version 60, perhaps this would be a good candidate to try out "LTS" / Long term support: #16622

Datafusion 56.0 will be in a good stable condition for downstream consumers and should be good starting point for new projects. So LTS makes sense.

@hareshkh

FYI @hareshkh who was asking about a more stable branch / backports in the call today

Adjusting date from Oct --> Oct/Nov as we are also working on a 55.2:

Release DataFusion 55.2.0 (patch) Release (Oct 2026) #25758

I would like to land a fix for #25883 before next release

[branch-55] fix: frame IPC messages when reading spill files so batch…

👋🏽 Flagging a couple changes I would like to see in df56 :)

I'd like #26211 in 56.0.0. It fixes a regression on main: this query works on 55.0.0 and fails on main.

create table s (g varchar, k varchar, x decimal(18,6)) as values ('a', 'u1', 1.5), ('a', 'u2', 2.5), ('b', 'u1', 3.0);
select g, nullif(sum(x), 0) as s, count(*) as n, count(distinct k) as d from s group by g order by g;

Arrow error: Invalid argument error: Invalid comparison operation: Decimal128(38, 6) == Decimal128(28, 6)

It starts failing at #24859, which lets SingleDistinctToGroupBy rewrite an aggregate with a count(*) next to the distinct aggregate, and so exposes the rule's decimal type bug (#26193). With #26211 it returns the same rows as 55.0.0. Query q158 of the dbolympics benchmark (#26661) fails the same way.

I would also like to burn down the wrong results bugs on main as well

[EPIC] A Collection of Wrong Results Bugs - Q4 2026 #26672

@Jefffrey

What is our thinking about timing of this release? Given I just helped @Jefffrey do a bunch of arrow releases (though Jeffrey I personally don't feel like I have the bandwidth to run a release this upcoming week (Oct 26)

Perhaps we could aim to make an RC the first week of Nov?

The mentioned PR #25887 introduced support for per-catalog information schemas and a 'system' catalog that is used to implement SHOW statements which still need to be able to report across all catalogs.

PR #26057 follows this up with full decoupling of SHOW statements from the information schema tables. This obviates the need for that 'system' catalog. It would be great if we could get #26057 merged for 56.0 still so that we don't introduce something new only to remove it in the next release.

26. Perhaps we could aim to make an RC the first week of Nov?

Makes sense, I'll work on it

@xudong963

I will try and prioritize reviewing and merging the issues linked to this ticket in the next week or so. Thank you @xudong963

To prepare the release, I have this PR that updates the update-version script so it modifies in all places currently in use: #26007

I think the versions need to be updated on main as soon as the new branch is cut as otherwise the new PRs' release labels (#25776) will refer to a wrong version.

Awesome -- I also want to start publishing versioned docs

docs: add version picker and manual release snapshots #24792

This is sounding like our existing release process is going to get more complicated. I agree more automation would be great...

Like maybe we should change the version on main to 56.0.0-dev or something, so that when we make a release branch we can immediately change main to 57.0.0-dev 🤔

I would love to land #26565 in this release so that it's not a breaking change later.

27. Like maybe we should change the version on main to 56.0.0-dev or something, so that when we make a release branch we can immediately change main to 57.0.0-dev 🤔

I've always been surprised that main doesn't bump to the next version when a release branch is cut.

@adriangb

Would be nice to get this on landed as well cc @adriangb:

feat: allow extension DataSources to decode via a per-type registry #26555

As other wise the proto type-registry refactor will be shipped in an intermediate state (#24631 and #24628 by @adriangb).

Navigation Menu

Repository navigation

Release DataFusion `56.0.0` (Oct/Nov 2026) #24461

Is your feature request related to a problem or challenge?

Features to mention in the blog (if they make it)

Bugs/issues that should be fixed

Community Wishlist

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Release DataFusion 56.0.0 (Oct/Nov 2026) #24461

Description

Is your feature request related to a problem or challenge?

Features to mention in the blog (if they make it)

Bugs/issues that should be fixed

Community Wishlist

Activity

xudong963 commented on Aug 26, 2026

Xuanwo commented on Sep 9, 2026

alamb commented on Sep 9, 2026

Xuanwo commented on Sep 14, 2026

alamb commented on Sep 15, 2026

alamb commented on Sep 15, 2026

kumarUjjawal commented on Sep 15, 2026

alamb commented on Sep 16, 2026

alamb commented on Sep 28, 2026

adriangb commented on Sep 30, 2026

jayshrivastava commented on Oct 22, 2026

jayzhan211 commented on Oct 24, 2026

alamb commented on Oct 25, 2026

alamb commented on Oct 25, 2026

pepijnve commented on Oct 26, 2026

xudong963 commented on Oct 26, 2026

alamb commented on Oct 26, 2026

nuno-faria commented on Oct 26, 2026

alamb commented on Oct 26, 2026

alamb commented on Oct 26, 2026

adriangb commented on Oct 26, 2026

mbutrovich commented on Oct 27, 2026

gabotechs commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Release DataFusion `56.0.0` (Oct/Nov 2026) #24461