Debezium version support and maintenance policy

[ff.la...@gmail.com]

Hi everyone,

I'd like to better understand Debezium's version deprecation and support policy.

From the releases page (https://debezium.io/releases/) I can see the list of versions with labels such as "stable", "latest stable" and "development", but it is not entirely clear what these imply in terms of ongoing maintenance and support. There is also a "Tested Versions" section that currently goes back to version 2.7 and I'm unsure whether this should be interpreted as the set of actively supported versions.

To make this more concrete: if a production system is currently running Debezium 2.5., what expectations should be set regarding maintenance, particularly for security fixes? For example, if a vulnerability were discovered in one of Debezium 2.5's dependencies, would a patch release be issued for 2.5 or are fixes only backported to versions listed under "Tested Versions"? In other words, is 2.5 considered stable but effectively unmaintained at this point?

Based on this, should projects still on 2.5 plan to upgrade to 2.7 (or later) in order to remain within the supported window, and what are the general expectations around upgrade cadence?
Apologies for the long message, but this is an important topic for production planning and I couldn't find clear guidance in the documentation.

Thanks in advance for any clarification.

Cheers,
Francesco

[Chris Cranford]

Hi Francesco,

For Debezium community builds, our policy is to provide support for the latest stable and the current active development branches. So currently in Q1 2026, the team is actively developing Debezium 3.5.x, and so we currently provide community support for both 3.4 and 3.5. This is one advantage of purchasing a support agreement for Debezium from Red Hat, we provide support back to earlier versions. 

In terms of the website documentation and releases, this is always a rolling list of versions. We keep the latest development and stable builds, and potentially at least once prior stable release visible, along with the latest release of the prior major version. This makes these links to documentation and release notes more accessible and prevents users from needing to click the "See older series" button.

When you click into a release, the "Tested Versions" section just documents the versions of sub-components we tested that release of Debezium with. For example, Debezium 2.7 was tested with Java 11 while Debezium 3.x is Java 17+.

So with all that in mind, if you're using Debezium community builds you'd want to ideally be on Debezium 3.4. Debezium 2.x has not been supported for over a year at this point.

Hope that helps.
-cc

Francesco --
You received this message because you are subscribed to the Google Groups "debezium" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debezium+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/debezium/efaa0854-77a8-4966-a2b0-3bbb825d085dn%40googlegroups.com.

[Francesco la Torre]

Hi Chris,

Thanks for the clarification, that's very helpful!

As a follow-up, in the event that a security vulnerability is identified in Debezium 2.x while a production system is still in the process of upgrading to a supported version, what are the available options? Specifically, if we plan to implement a fix ourselves and raise a PR on github, would it be possible to have that change included in a new patched release of the 2.x line (for example, 2.x.y) and made available on Maven Central? or is upgrading to a currently supported version the only viable path to receive security updates under the community model?

This would help us plan risk mitigation strategies during the upgrade window.

Thanks again.
Francesco

To view this discussion visit https://groups.google.com/d/msgid/debezium/e1e57a55-8664-4b81-817a-d7426d39622b%40gmail.com.

[Chris Cranford]

Hi -

That's a great question.

In practice, we do not publish new releases for Debezium versions that are no longer maintained, which at this point would be anything prior to 3.4. However, just because we don't publish new releases does not mean we aren't willing to accept pull requests to address problems for those who are willing to build from source. 

For CVEs, this can be tricky on older branches, and the older the branch the more complicated it becomes. These are best left to a case-by-case evaluation to understand the impact. Remember, Debezium is published with specific compatibility targets in mind, e.g. Kafka X.Y.  If the CVE patch requires updating a specific target to a new major/minor version rather than applying a maintenance patch for the same current major.minor version, then we break that compatibility target and that's not acceptable.

So you're welcomed to submit pull requests at any time for anything you believe to be relevant, but we'll need to evaluate it on a case-by-case basis.

Thanks,
-cc

To view this discussion visit https://groups.google.com/d/msgid/debezium/CADa9NFdV%2B%2Bqvo5fx3JRqh96EHceB0ovdqYMLhYcJ6gxUR8TSkA%40mail.gmail.com.

[jiri.p...@gmail.com]

Hi,

we'll accept the PR into the source tree but we will not cut another 2.x release. So you can still build the version from source and use it as you need.

Jiri

[Francesco la Torre]

Chris, Jiri,

Thanks a lot for the clarification.

Cheers,

Francesco

To view this discussion visit https://groups.google.com/d/msgid/debezium/aacbb53b-4e9e-4adb-9cbc-27500751ceb5n%40googlegroups.com.