WS6: Finalize the public API before GA
I maintainer di solito rispondono entro 1 giorno
@j7nw4r ci sta già lavorando.
Dal 28/7/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Summary
The public API must be settled before 1.0.0, because only backwards compatible growth is permitted after GA. The Azure SDK architecture board review is not complete, no archived API surface artifact exists, the error model carries a raw AMQP condition string with no reason enum, several transport options that .NET exposes are absent, and vcpkg.json declares a wrong version and an unused dependency.
Severity tags follow the key in #7252.
Motivation
The Azure SDK release checklist requires an architecture board API review and an archived API surface artifact. .NET keeps that artifact as sdk/eventhub/Azure.Messaging.EventHubs/api/Azure.Messaging.EventHubs.netstandard2.0.cs. The C++ package has no equivalent.
EventHubsException carries a raw condition string, a description, an IsTransient flag, and an optional status code (inc/azure/messaging/eventhubs/eventhubs_exception.hpp:38-65). .NET maps errors onto a FailureReason enum with eleven values (sdk/eventhub/Azure.Messaging.EventHubs/src/EventHubsException.cs:221-255), which gives a caller something to act on without parsing a string.
The C++ versioning guidelines state "DO be 100% backwards compatible with older versions of the same package" [cpp-versioning-backwards-compatibility] and "DO introduce a new package (with new assembly names, new namespace names, and new type names) if you must do an API breaking change" [cpp-versioning-new-package]. The C++ guidelines record no ABI or binary compatibility promise, so the constraint is source compatibility.
A sweep of the C++ options structs did not find a per-attempt timeout, a retry mode, WebSocket transport, a proxy, or a custom endpoint, all of which .NET exposes through EventHubsRetryOptions and EventHubConnectionOptions. That sweep was not exhaustive, so each item needs a decision rather than an assumption.
vcpkg.json declares version-string: 1.0.0 while the package is at a beta version, and it declares an opentelemetry-cpp dependency with the otlp-http feature that the library sources do not use (vcpkg.json:3-11). Note that #7259 may make that dependency real.
Proposal
- Complete the Azure SDK architecture board API review for
azure-messaging-eventhubsandazure-messaging-eventhubs-checkpointstore-blob. Produce and archive the API surface listing, the C++ analog of the .NETapi/*.csfiles. [GA blocker] - Decide whether the reason enum supplements the condition string or replaces it. A replacement is a breaking change and must land before
1.0.0. [GA blocker to decide] - Add a reason enum mapped from AMQP conditions, modeled on
EventHubsException.cs:221-255, as a new member alongside the existing fields (inc/azure/messaging/eventhubs/eventhubs_exception.hpp:38-65). [GA quality bar] - Sweep
ConsumerClientOptionsandProducerClientOptionsagainst the .NETEventHubsRetryOptionsandEventHubConnectionOptions. Decide each missing option as add-before-GA, add-after-GA, or never. [GA quality bar] - Correct
vcpkg.json: fixversion-string, and remove or justify the unusedopentelemetry-cppdependency (vcpkg.json:3-11). [GA quality bar]
Resolution of the earlier open question
This issue previously tagged the reason enum GA quality bar on the unverified assumption that the C++ SDK permits additive API growth after 1.0.0. The guidelines were then read directly, and they permit it: cpp-versioning-backwards-compatibility constrains source compatibility, and adding a new enum type plus a new accessor to EventHubsException keeps every existing caller compiling.
The tag therefore stays GA quality bar, but it holds only for a supplement. Removing or repurposing the existing condition string breaks callers and must land before 1.0.0. That is why the supplement-or-replace decision is split out above as its own blocker.
One caveat: the guidelines record no ABI promise, so adding a member to the exception class is safe for source builds but changes the class layout. Consumers who link a prebuilt binary must rebuild. Record that expectation with the decision.
Validation
- The architecture board sign-off is recorded and the API surface artifact is archived in the repository.
- The supplement-or-replace decision is recorded in this issue.
- Every option in the sweep carries a recorded decision.
-
vcpkg.jsondeclares the correct version and no unused dependency.
- Lingua principale
- C++
- Stelle
- 206
- Fork
- 173
- Merge medio
- 2g 4h
- PR unite (30g)
- 27
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Azure/azure-sdk-for-cpp
-
bug EngSys
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
Azure/azure-sdk-for-cpp#7362 ·
I maintainer di solito rispondono entro 1 giorno
-
Client needs-team-attention Service Attention Storage
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Azure/azure-sdk-for-cpp#7347 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Client Event Hubs needs-team-attention Service Attention
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
Azure/azure-sdk-for-cpp#7333 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
DataLakeDirectoryClient::ListPaths() throws exception for folders whose names contain spaces.Forse già presa @Jinming-Hu l’ha presa oggi. ApertaClient customer-reported question Service Attention Storage
Azure/azure-sdk-for-cpp#7475 · 2 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
Azure Storage STG105 Feature TestsForse già presa @Jinming-Hu l’ha presa 11 giorni fa. ApertaClient Storage
Azure/azure-sdk-for-cpp#7449 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Azure/azure-sdk-for-cpp
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement question
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
DarkStarSystems/pcons#224 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
LizardByte/Sunshine#5953 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
(S1 - Need confirmation)
Difficoltà 2/5 1-3 ore Idoneità per principianti 63/100
CleverRaven/Cataclysm-DDA#89133 ·
I maintainer di solito rispondono entro 1 giorno