Skip to content

Release DataFusion 56.0.0 (Oct/Nov 2026) #24461

Open

Description

@alamb

Is your feature request related to a problem or challenge?

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

Community Wishlist

Activity

  1. changed the title [-]Release DataFusion `56.0.0` (Sep / Oct 2026)[/-] [+]Release DataFusion `56.0.0` (Oct 2026)[/+] on Aug 18, 2026
  2. xudong963 commented on Aug 26, 2026

    @xudong963
    Member

    I can help with this release!

  3. self-assigned this
    on Aug 26, 2026
  4. Xuanwo commented on Sep 9, 2026

    @Xuanwo
    Member

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

  5. alamb commented on Sep 9, 2026

    @alamb
    ContributorAuthor

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

  6. Xuanwo commented on Sep 14, 2026

    @Xuanwo
    Member

    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.

  7. alamb commented on Sep 15, 2026

    @alamb
    ContributorAuthor

    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

  8. alamb commented on Sep 15, 2026

    @alamb
    ContributorAuthor

    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

  9. kumarUjjawal commented on Sep 15, 2026

    @kumarUjjawal
    Contributor

    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.

  10. alamb commented on Sep 16, 2026

    @alamb
    ContributorAuthor

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

  11. changed the title [-]Release DataFusion `56.0.0` (Oct 2026)[/-] [+]Release DataFusion `56.0.0` (Oct/Nov 2026)[/+] on Sep 28, 2026
  12. alamb commented on Sep 28, 2026

    @alamb
    ContributorAuthor

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

  13. adriangb commented on Sep 30, 2026

    @adriangb
    Contributor

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

  14. jayshrivastava commented on Oct 22, 2026

    @jayshrivastava
    Contributor
  15. jayzhan211 commented on Oct 24, 2026

    @jayzhan211
    Contributor

    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.

  16. alamb commented on Oct 25, 2026

    @alamb
    ContributorAuthor

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

  17. alamb commented on Oct 25, 2026

    @alamb
    ContributorAuthor

    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?

  18. pepijnve commented on Oct 26, 2026

    @pepijnve
    Contributor

    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.

  19. xudong963 commented on Oct 26, 2026

    @xudong963
    Member

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

    Makes sense, I'll work on it

  20. alamb commented on Oct 26, 2026

    @alamb
    ContributorAuthor

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

  21. pinned and unpinned a comment on Oct 26, 2026
  22. nuno-faria commented on Oct 26, 2026

    @nuno-faria
    Contributor

    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.

  23. alamb commented on Oct 26, 2026

    @alamb
    ContributorAuthor

    Awesome -- I also want to start publishing versioned docs

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

  24. alamb commented on Oct 26, 2026

    @alamb
    ContributorAuthor

    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 🤔

  25. adriangb commented on Oct 26, 2026

    @adriangb
    Contributor

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

  26. mbutrovich commented on Oct 27, 2026

    @mbutrovich
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions