On behalf of the team and everyone who contributed, we are pleased to announce that Spring for Apache Kafka 4.1.0-RC1 , 4.0.5 , and 3.3.15 have been released. We extend our gratitude to all contributors who made these releases possible. A broader walkthrough of what is new in the 4.1 line thus far compared with 4.0 is in the What’s New in 4.1 Since 4.0 chapter of the reference manual. What's New in 4.1.0-RC1 Share consumer ShareAckMode ( #4376 ): Container configuration now uses a ShareAckMode enum ( EXPLICIT , MANUAL , IMPLICIT ) in place of the deprecated boolean on ContainerProperties ; defaults are unchanged for existing apps. Details: Record acknowledgment . Async commits ( #4324 , #4380 ): The share container can use asynchronous acknowledgment commits; AcknowledgementCommitCallback is provided as a commit callback for the user to have further control. Details: Synchronous vs asynchronous commits . share.acquire.mode ( #4326 ): Built-in validation ensures share.acquire.mode ( KIP-1206 ) is wired correctly through Spring’s configuration model. Details: Acquire mode . Lifecycle events ( #4327 ): ShareKafkaMessageListenerContainer publishes additional stop and failure events alongside the existing start events. Details: Lifecycle events . Kafka Streams group.protocol ( #4329 ): StreamsBuilderFactoryBean exposes groupProtocol so you can choose the classic consumer protocol or the Streams group protocol for server-side rebalance ( KIP-1071 ). Details: Group protocol . Native DLQ and Streams exception handlers ( #4328 ): Kafka 4.2’s KIP-1034 extends deserialization, processing, and production exception handlers with a shared handleError() contract and optional dead-letter records issued by Kafka Streams itself. Spring Kafka has traditionally used, RecoveringDeserializationExceptionHandler along with DeadLetterPublishingRecoverer + KafkaTemplate . This release lines up Spring Kafka’s recovering handlers for Kafka Streams with KIP-1034: RecoveringDeserializationExceptionHandler is updated, and RecoveringProcessingExceptionHandler / RecoveringProductionExceptionHandler are added. When you configure a DLQ topic, a destination resolver, or the factory bean’s dead-letter topic name, failures can follow the native DLQ route; when you do not, behavior stays with the recoverer-based path you already rely on. Handler wiring and DLQ options: Deserialization recovery , Processing recovery , Production recovery . Other fixes and documentation Async processing with filtered messages ( FilteringMessageListenerAdapter ) ( #4377 ) ShareKafkaMessageListenerContainer.doStart() waits for the consumer thread ( #4357 ) StreamsBuilderFactory properties remain immutable after initialization ( #4382 ) JSpecify @Nullable on consumer and producer factories ( #4355 ) Clearer container-properties documentation for messageListener ( #4417 ) 4.0.5 and 3.3.15 (patch releases) Patch releases 4.0.5 and 3.3.15 carry the same kinds of fixes we shipped in 4.1.0-RC1 where they apply to those branches. 4.0.5 includes fixes for filtering with async commits, share container startup, StreamsBuilderFactory immutability, factory nullability annotations, Kafka client patch alignment, and current Spring stack BOMs (Spring Framework, Reactor, Micrometer, tracing, Spring Data, logging). 3.3.15 brings the FilteringMessageListenerAdapter fix and Framework/Reactor maintenance bumps for the 3.3.x line. Release notes More details along with any dependency updates and other changes can be found in the release notes. 4.1.0-RC1 4.0.5 3.3.15 Spring Boot integration Spring Kafka 3.3.15 will be integrated into Spring Boot 3.5.14 . Spring Kafka 4.0.5 will be integrated into Spring Boot 4.0.6 . Spring Kafka 4.1.0-RC1 will be integrated into Spring Boot 4.1.0-RC1 . Community feedback Feedback and issue reports are welcome on GitHub . GitHub | Project Page | Documentation