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
The Quarkus 4 working group aims to coordinate and track all Quarkus 4-related development in a long-running effort.
7
+
readme: |
8
+
<h2>Objective</h2>
9
+
<p>This long‑running working group is dedicated to tracking development and ensuring a smooth rollout for Quarkus 4. It will serve as the central coordination point for feature tracking, release hygiene, migration guidance, and community alignment related to Quarkus 4.</p>
10
+
<h2>The Problem</h2>
11
+
<p>Quarkus 4 introduces significant shifts, including new Java 25 flags, architectural refinements, deprecations, and ecosystem changes. Without a focused group, efforts become fragmented, and downstream consumers (extensions, integrations, platform partners) may struggle to stay aligned.</p>
12
+
<h2>Proposed Solution</h2>
13
+
<p>Establish a designated WG to:</p>
14
+
<ul>
15
+
<li>Track all Quarkus 4‑related issues and PRs (using label triage/quarkus-4)</li>
16
+
<li>Maintain a GitHub project board for feature status, blockers, and timelines</li>
17
+
<li>Coordinate across teams (core, extensions, platform, tooling)</li>
18
+
<li>Surface migration considerations and flag impacts (e.g. new --add-opens needs, optimized defaults) - useful to create the migration guide and rules</li>
19
+
<li>Publish ADRs, migration guides, and summary docs</li>
20
+
</ul>
21
+
<h2>Definition of Done</h2>
22
+
<p>This WG will be considered complete when:</p>
23
+
<ul>
24
+
<li>Quarkus 4 GA is released (including the platform)</li>
25
+
<li>All major features are merged and tested</li>
26
+
<li>Migration documentation is publicly available</li>
27
+
</ul>
28
+
<h2>Organizing the Work</h2>
29
+
<p>Coordination via:</p>
30
+
<ul>
31
+
<li>GitHub Discussions: use design‑discussions category</li>
32
+
<li>Issues/PRs: label with <code>triage/quarkus-4</code></li>
33
+
<li>Project board to track status</li>
34
+
</ul>
35
+
<h2>Expected Timeline:</h2>
36
+
<p>This is a long-running WG, starting now and wrapping up post‑GA (~late Q2 2026). We’ll mark it as “done” upon the public release of Quarkus 4 GA.</p>
37
+
status: on track
38
+
lts: false
39
+
completed: false
40
+
last-activity: 2026-05-04
41
+
last-update-date: 2026-03-30
42
+
last-update: |
43
+
The team closed out significant work on the Vert.x 5 upgrade and migration of its core extension for Quarkus 4. New tasks include updating Vert.x configuration, reworking CI, and addressing Kafka Kerberos authentication in native mode. We're also defining OpenTelemetry trace sampling defaults and looking into extension modularity.
44
+
45
+
(This status update was automatically generated using AI.)
Observability.Next is a strategic initiative to modernize the observability stack within the Quarkus framework, aiming to streamline and enhance its ability to monitor and manage distributed systems.
50
+
readme: |
51
+
<h2>Overview</h2>
52
+
<p>Observability.Next is a strategic initiative to modernize the observability stack within the Quarkus framework, aiming to streamline and enhance its ability to monitor and manage distributed systems. Currently, Quarkus (3.16.x) leverages the following components for observability:
53
+
Metrics: Managed through <a href="https://micrometer.io/">Micrometer</a>, which supports multiple registries (e.g., Prometheus) to expose application metrics.
54
+
Tracing: Handled via the OpenTelemetry (OTEL) SDK, enabling distributed tracing data to be exported to an OTEL collector.
55
+
Logging: JBoss's LogManager with a handler forwarding logs with OTEL.</p>
56
+
<p>While OpenTelemetry is the industry standard for observability, both in protocol and format, the OTEL SDK has proven challenging to adapt due to its design for agent-based observability. In a framework like Quarkus, more granular and direct control over observability is required to monitor application performance, reliability, and user experience effectively.</p>
57
+
<p>Micrometer, the de-facto Java standard for metrics, has recently proposed an enhanced, global approach to observability with the new Observation API. Expanding Micrometer’s role in Quarkus’ observability stack represents an opportunity to simplify implementation and maintenance while preserving compatibility with leading observability tools.</p>
58
+
<h2>Objectives</h2>
59
+
<p>The Observability.Next initiative seeks to strengthen the integration of Micrometer’s evolving Observability API within Quarkus, aligning it with OpenTelemetry’s protocol standards. Key objectives include:</p>
60
+
<ul>
61
+
<li>Enhanced Observability Control: Implement a framework-native, Micrometer-centric approach to metrics, traces, and logs, ensuring developers have more refined control over observability components without the limitations of the OTEL SDK.</li>
62
+
<li>Broader Metrics and Tracing Compatibility: Continue exposing metrics to various registries, including Prometheus, while maintaining OTEL compatibility for metrics and tracing protocols.
63
+
Improved Performance and Reliability: Define and measure performance baselines of the current observability setup and compare them against the next-to-be Micrometer Observation API and OTEL bridge integration to ensure tangible performance and reliability improvements.
64
+
Continue to support components using Micrometer metrics API or Open * Telemetry SDK (like Pulsar)</li>
65
+
</ul>
66
+
<h2>Scope</h2>
67
+
<p>Observability.Next will unfold across multiple phases, each handled by specialised working groups. The scope of the initial working group will include:</p>
68
+
<ul>
69
+
<li>Micrometer Observation API Integration: Introduce and integrate Micrometer’s observability API as a foundational layer</li>
70
+
<li>Transformation to OTEL Protocols: Develop a mechanism to translate Micrometer-collected observations into OTEL-compatible metrics, traces, and logs, ensuring smooth interoperability with OTEL-based tools and collectors.</li>
71
+
<li>Performance Benchmarking: Establish a performance baseline for Quarkus’ current observability model, comparing it against the new Micrometer-based observability API and OTEL bridge to quantify gains and identify areas for further optimisation.</li>
72
+
</ul>
73
+
<h2>Expected Outcomes</h2>
74
+
<ul>
75
+
<li></li>
76
+
<li>Improved Developer Experience: More intuitive, refined control over observability for Quarkus developers, reducing complexity and overhead associated with setting up and maintaining observability.</li>
77
+
<li>Ecosystem Compatibility: Continued compatibility with existing observability tools such as Prometheus and OTEL collectors, ensuring interoperability with common enterprise monitoring solutions.</li>
78
+
<li>Less breakage due to the OTEL SDK</li>
79
+
<li>More control over the semantic convention in span and metric tags</li>
80
+
<li>Performance Gains: Potentially lower latency and resource consumption in observability operations, contributing to Quarkus’ goal of high-performance, cloud-native applications.</li>
81
+
</ul>
82
+
<p>Some concrete features we would get at the framework level:</p>
83
+
<ul>
84
+
<li>Instrument once, plug different frameworks later</li>
85
+
<li>Better support of scopes than the one we have today. See:
86
+
https://github.com/quarkusio/quarkus/issues/25102 and
<li>Micrometer, Observation API and OpenTelemetry roadmap: https://groups.google.com/g/quarkus-dev/c/y5-ojIVsa_M/m/4wquJi4bBQAJ</li>
109
+
</ul>
110
+
</li>
111
+
</ul>
112
+
status: on track
113
+
lts: false
114
+
completed: false
115
+
last-activity: 2026-05-04
116
+
last-update-date: 2026-03-30
117
+
last-update: |
118
+
For Observability.Next, the team is actively investigating a few key areas. We're looking into Micrometer Prometheus `http_server_bytes_read` registration issues with the management interface. We're also addressing correlated span problems in the Vert.x event bus and OpenTelemetry context loss for `blocking @ConsumeEvent` with fire-and-forget messages.
119
+
120
+
(This status update was automatically generated using AI.)
The Quarkus 4 working group aims to coordinate and track all Quarkus 4-related development in a long-running effort.
222
-
readme: |
223
-
<h2>Objective</h2>
224
-
<p>This long‑running working group is dedicated to tracking development and ensuring a smooth rollout for Quarkus 4. It will serve as the central coordination point for feature tracking, release hygiene, migration guidance, and community alignment related to Quarkus 4.</p>
225
-
<h2>The Problem</h2>
226
-
<p>Quarkus 4 introduces significant shifts, including new Java 25 flags, architectural refinements, deprecations, and ecosystem changes. Without a focused group, efforts become fragmented, and downstream consumers (extensions, integrations, platform partners) may struggle to stay aligned.</p>
227
-
<h2>Proposed Solution</h2>
228
-
<p>Establish a designated WG to:</p>
229
-
<ul>
230
-
<li>Track all Quarkus 4‑related issues and PRs (using label triage/quarkus-4)</li>
231
-
<li>Maintain a GitHub project board for feature status, blockers, and timelines</li>
232
-
<li>Coordinate across teams (core, extensions, platform, tooling)</li>
233
-
<li>Surface migration considerations and flag impacts (e.g. new --add-opens needs, optimized defaults) - useful to create the migration guide and rules</li>
234
-
<li>Publish ADRs, migration guides, and summary docs</li>
235
-
</ul>
236
-
<h2>Definition of Done</h2>
237
-
<p>This WG will be considered complete when:</p>
238
-
<ul>
239
-
<li>Quarkus 4 GA is released (including the platform)</li>
240
-
<li>All major features are merged and tested</li>
241
-
<li>Migration documentation is publicly available</li>
242
-
</ul>
243
-
<h2>Organizing the Work</h2>
244
-
<p>Coordination via:</p>
245
-
<ul>
246
-
<li>GitHub Discussions: use design‑discussions category</li>
247
-
<li>Issues/PRs: label with <code>triage/quarkus-4</code></li>
248
-
<li>Project board to track status</li>
249
-
</ul>
250
-
<h2>Expected Timeline:</h2>
251
-
<p>This is a long-running WG, starting now and wrapping up post‑GA (~late Q2 2026). We’ll mark it as “done” upon the public release of Quarkus 4 GA.</p>
252
-
status: on track
253
-
lts: false
254
-
completed: false
255
-
last-activity: 2026-04-30
256
-
last-update-date: 2026-03-30
257
-
last-update: |
258
-
The team closed out significant work on the Vert.x 5 upgrade and migration of its core extension for Quarkus 4. New tasks include updating Vert.x configuration, reworking CI, and addressing Kafka Kerberos authentication in native mode. We're also defining OpenTelemetry trace sampling defaults and looking into extension modularity.
259
-
260
-
(This status update was automatically generated using AI.)
Observability.Next is a strategic initiative to modernize the observability stack within the Quarkus framework, aiming to streamline and enhance its ability to monitor and manage distributed systems.
284
-
readme: |
285
-
<h2>Overview</h2>
286
-
<p>Observability.Next is a strategic initiative to modernize the observability stack within the Quarkus framework, aiming to streamline and enhance its ability to monitor and manage distributed systems. Currently, Quarkus (3.16.x) leverages the following components for observability:
287
-
Metrics: Managed through <a href="https://micrometer.io/">Micrometer</a>, which supports multiple registries (e.g., Prometheus) to expose application metrics.
288
-
Tracing: Handled via the OpenTelemetry (OTEL) SDK, enabling distributed tracing data to be exported to an OTEL collector.
289
-
Logging: JBoss's LogManager with a handler forwarding logs with OTEL.</p>
290
-
<p>While OpenTelemetry is the industry standard for observability, both in protocol and format, the OTEL SDK has proven challenging to adapt due to its design for agent-based observability. In a framework like Quarkus, more granular and direct control over observability is required to monitor application performance, reliability, and user experience effectively.</p>
291
-
<p>Micrometer, the de-facto Java standard for metrics, has recently proposed an enhanced, global approach to observability with the new Observation API. Expanding Micrometer’s role in Quarkus’ observability stack represents an opportunity to simplify implementation and maintenance while preserving compatibility with leading observability tools.</p>
292
-
<h2>Objectives</h2>
293
-
<p>The Observability.Next initiative seeks to strengthen the integration of Micrometer’s evolving Observability API within Quarkus, aligning it with OpenTelemetry’s protocol standards. Key objectives include:</p>
294
-
<ul>
295
-
<li>Enhanced Observability Control: Implement a framework-native, Micrometer-centric approach to metrics, traces, and logs, ensuring developers have more refined control over observability components without the limitations of the OTEL SDK.</li>
296
-
<li>Broader Metrics and Tracing Compatibility: Continue exposing metrics to various registries, including Prometheus, while maintaining OTEL compatibility for metrics and tracing protocols.
297
-
Improved Performance and Reliability: Define and measure performance baselines of the current observability setup and compare them against the next-to-be Micrometer Observation API and OTEL bridge integration to ensure tangible performance and reliability improvements.
298
-
Continue to support components using Micrometer metrics API or Open * Telemetry SDK (like Pulsar)</li>
299
-
</ul>
300
-
<h2>Scope</h2>
301
-
<p>Observability.Next will unfold across multiple phases, each handled by specialised working groups. The scope of the initial working group will include:</p>
302
-
<ul>
303
-
<li>Micrometer Observation API Integration: Introduce and integrate Micrometer’s observability API as a foundational layer</li>
304
-
<li>Transformation to OTEL Protocols: Develop a mechanism to translate Micrometer-collected observations into OTEL-compatible metrics, traces, and logs, ensuring smooth interoperability with OTEL-based tools and collectors.</li>
305
-
<li>Performance Benchmarking: Establish a performance baseline for Quarkus’ current observability model, comparing it against the new Micrometer-based observability API and OTEL bridge to quantify gains and identify areas for further optimisation.</li>
306
-
</ul>
307
-
<h2>Expected Outcomes</h2>
308
-
<ul>
309
-
<li></li>
310
-
<li>Improved Developer Experience: More intuitive, refined control over observability for Quarkus developers, reducing complexity and overhead associated with setting up and maintaining observability.</li>
311
-
<li>Ecosystem Compatibility: Continued compatibility with existing observability tools such as Prometheus and OTEL collectors, ensuring interoperability with common enterprise monitoring solutions.</li>
312
-
<li>Less breakage due to the OTEL SDK</li>
313
-
<li>More control over the semantic convention in span and metric tags</li>
314
-
<li>Performance Gains: Potentially lower latency and resource consumption in observability operations, contributing to Quarkus’ goal of high-performance, cloud-native applications.</li>
315
-
</ul>
316
-
<p>Some concrete features we would get at the framework level:</p>
317
-
<ul>
318
-
<li>Instrument once, plug different frameworks later</li>
319
-
<li>Better support of scopes than the one we have today. See:
320
-
https://github.com/quarkusio/quarkus/issues/25102 and
<li>Micrometer, Observation API and OpenTelemetry roadmap: https://groups.google.com/g/quarkus-dev/c/y5-ojIVsa_M/m/4wquJi4bBQAJ</li>
343
-
</ul>
344
-
</li>
345
-
</ul>
346
-
status: on track
347
-
lts: false
348
-
completed: false
349
-
last-activity: 2026-04-28
350
-
last-update-date: 2026-03-30
351
-
last-update: |
352
-
For Observability.Next, the team is actively investigating a few key areas. We're looking into Micrometer Prometheus `http_server_bytes_read` registration issues with the management interface. We're also addressing correlated span problems in the Vert.x event bus and OpenTelemetry context loss for `blocking @ConsumeEvent` with fire-and-forget messages.
353
-
354
-
(This status update was automatically generated using AI.)
0 commit comments