You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Who is this for and what problem do they have today?
AutoMQ users facing bugs and security vulnerabilities caused by old dependencies and Docker images.
Why is solving this problem impactful?
I guess most code is still coming from Kafka upstream, that would explain the large technical debt (many outdated versions).
Updating as many dependencies and Docker images as possible does not only fix security vulnerabilities, but also fixes other bugs and allows using new features.
Just look at a current trivy scan of confluentinc/cp-kafka to see how many months they wait until updating a single dependency...
Additional notes
If updates are welcome in this project (for example you updated minJavaVersion 5 months ago) I could provide a first PR with what updates I can find and a Dependabot config to automate this tedious process in the future.
Just by looking for a minute through main I saw already dozens of updates (i.e. kafka 3.7.1 and 3.8.0, Guava, JDK, GraalVM, Gradle, Maven, ...).
The text was updated successfully, but these errors were encountered:
Updating dependencies is not just about updating versions; it is a more complex task that requires additional effort in compatibility adaptation, performance regression, and other preparatory tasks.
The dependencies of Apache Kafka upstream have been verified by a large number of users in the community, so AutoMQ currently adopts a dependency version update strategy that follows Apache Kafka upstream.
I see, maybe you want to make these invisible barriers preventing reducing technical debt more transparent by writing tests showing that performance is "100%" now with those old dependencies, so updates that reduce performance can be identified automatically?
That all major frameworks are compatible like Spring Boot 3.3 + Spring Kafka 3.2 + Spring Cloud Stream 4.1 and Quarkus 3.13 + SmallRye Reactive Messaging 4.18 and Micronaut 4.6 + Micronaut Kafka 5.5 to automatically show that an dependency update breaks compatibility in one component?
Updating Debian 11.3 (2.5 years old) to 12.6 (2 months old) would fix hundreds of vulnerabilities alone, leaving Java with 1 easy update fixing 2 vulnerabilities... but it's impossible because netty-codec-http 4.1.108 is slow and incompatible to 4.1.94? 🤔
Who is this for and what problem do they have today?
AutoMQ users facing bugs and security vulnerabilities caused by old dependencies and Docker images.
Why is solving this problem impactful?
I guess most code is still coming from Kafka upstream, that would explain the large technical debt (many outdated versions).
Updating as many dependencies and Docker images as possible does not only fix security vulnerabilities, but also fixes other bugs and allows using new features.
Just look at a current trivy scan of confluentinc/cp-kafka to see how many months they wait until updating a single dependency...
Additional notes
If updates are welcome in this project (for example you updated
minJavaVersion
5 months ago) I could provide a first PR with what updates I can find and a Dependabot config to automate this tedious process in the future.Just by looking for a minute through main I saw already dozens of updates (i.e. kafka 3.7.1 and 3.8.0, Guava, JDK, GraalVM, Gradle, Maven, ...).
The text was updated successfully, but these errors were encountered: