From b3367711e55054cb378532a790548b831095eb02 Mon Sep 17 00:00:00 2001 From: Tamas Juhasz Date: Thu, 27 Nov 2025 14:25:30 +0100 Subject: [PATCH 1/3] Updated README.md, Added Versioning.md --- README.md | 17 ++++++--- VERSIONING.md | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 112 insertions(+), 6 deletions(-) create mode 100644 VERSIONING.md diff --git a/README.md b/README.md index 79dc59d..a9d9370 100644 --- a/README.md +++ b/README.md @@ -197,21 +197,25 @@ Example of webhook implementation: } ``` #### Two-Factor Authentication (2FA) -For 2FA quick start guide please check [these examples](two-factor-authentication.md). +For the 2FA quick start guide please check [these examples](two-factor-authentication.md). #### Send email -For send email quick start guide please check [these examples](email.md). +For the send email quick start guide please check [these examples](email.md). #### Moments -For Flow & Forms quick start guide please check [these examples](moments.md). +For the Flow & Forms quick start guide please check [these examples](moments.md). + +## Versioning + +This project follows a pragmatic Semantic Versioning approach. +For full details on how versions are managed, please see our [Versioning guide][versioning]. ## Ask for help -Feel free to open issues on the repository for any issue or feature request. +Feel free to open an issue on the repository if you see any problem or want to request a feature. Check the `CONTRIBUTING` [file][contributing] for details about contributions - in short, we will not merge any pull requests since this code is auto-generated. -However, if you find something that requires our imminent attention feel free to contact us @ [support@infobip.com](mailto:support@infobip.com). - +However, if you find something that requires our immediate attention, feel free to contact us @ [support@infobip.com](mailto:support@infobip.com). [apidocs]: https://www.infobip.com/docs/api [freetrial]: https://www.infobip.com/docs/essentials/getting-started/free-trial [signup]: https://www.infobip.com/signup @@ -221,3 +225,4 @@ However, if you find something that requires our imminent attention feel free to [authentication-apikey]: https://www.infobip.com/docs/essentials/api-authentication#api-key-header [datetimeformat]: https://www.infobip.com/docs/essentials/api-essentials/integration-best-practices#date-formats-backward-compatibility [receive-inbound-sms]: https://www.infobip.com/docs/api/channels/sms/inbound-sms/receive-inbound-sms-messages +[versioning]: VERSIONING.md diff --git a/VERSIONING.md b/VERSIONING.md new file mode 100644 index 0000000..6545afb --- /dev/null +++ b/VERSIONING.md @@ -0,0 +1,101 @@ +# Versioning Strategy + +This document defines the versioning strategy for the Infobip C# API Client. + +--- + +## 1. Versioning Model + +The SDK follows a **pragmatic Semantic Versioning** model: + +``` +MAJOR.MINOR.PATCH +``` + +While we adhere to the core principles of SemVer, the SDK evolves in tandem with Infobip's backend APIs, which may require **occasional breaking changes in MINOR releases**. These will always be documented clearly. + +### Summary of Intent + +* **MAJOR** → Large, coordinated breaking changes across multiple areas, architectural redesigns, endpoint version migrations. +* **MINOR** → New features, new endpoints, model updates, and in some cases *breaking changes required by API correctness*. +* **PATCH** → Bug fixes, documentation fixes, safe dependency bumps. + +--- + +## 2. Change Classification + +### 2.1 Patch Changes (PATCH) + +PATCH versions include changes that are fully backward compatible: + +* Bug fixes. +* Typo and documentation corrections. +* Safe dependency upgrades. +* Internal refactors with no public API impact. + +--- + +### 2.2 New Features and API Updates (MINOR) + +MINOR versions introduce: + +* New endpoints, webhooks, or new request/response fields. +* Support for new message types, enums, or capabilities. +* Fixing wrong field types (e.g., `string` → `int`). +* Removing fields or models when upstream endpoints no longer support them. +* Unifying models (e.g., platform enums, validity windows, message statuses). +* Replacing request/response classes due to upstream schema changes. + +**Breaking changes may appear in MINOR releases** when necessary. + +--- + +### 2.3 Major Changes (MAJOR) + +MAJOR releases are reserved for **significant, multi-area-breaking changes**, such as: + +* Full API reorganization. +* Global unification or rework of API surface. +* Endpoint version migrations across several products. +* Architectural redesigns. +* Removal of deprecated features accumulated over multiple MINOR releases. + +--- + +## 3. Handling Upstream API Changes + +* **Correctness takes priority over C# API backward compatibility.** +* When upstream APIs change field types, remove fields, or alter schemas, the SDK must remain consistent. +* Such updates may cause MINOR releases to include breaking changes. +* These will always be documented with a ⚠️ note in the CHANGELOG. + +This ensures the SDK remains reliable and accurate for production usage. + +--- + +## 4. C# and Dependency Compatibility Policy + +### 4.1 Minimum C# Version Changes + +Increasing the **minimum targeted .NET/C# framework version** (e.g.,.NET Standard 2.0 → .NET 6.0) is always treated as a **MAJOR** version change. Such a change breaks compilation and runtime compatibility for existing users and therefore constitutes a breaking API change. + +### 4.2 Dependency Upgrade Policy + +**PATCH** + +* Only patch-level dependency updates are allowed (e.g., Polly 7.2.0 → 7.2.4). +* Must not introduce behavior changes, serialization differences, or require consumers to adjust their dependencies. +* Test/build-only dependency bumps are allowed. + +**MINOR** + +* Patch or minor dependency updates are allowed (e.g., Polly 7.0 → 7.2). +* No breaking serialization or model changes caused solely by dependency bumps. + +**MAJOR** + +* All dependency upgrades are allowed, including breaking changes. +* Major dependency upgrades (e.g., Polly 7 → 8) should be shipped in major releases. +* Framework switches, large refactors, or structural changes belong here. + +All dependency-related breaking changes will be clearly documented in the CHANGELOG. \ No newline at end of file From 2a7802b220a43688b46c6515c5fee0946532a4cf Mon Sep 17 00:00:00 2001 From: Tamas Juhasz Date: Fri, 28 Nov 2025 09:15:17 +0100 Subject: [PATCH 2/3] updated VERSIONING.md --- VERSIONING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSIONING.md b/VERSIONING.md index 6545afb..c75bb56 100644 --- a/VERSIONING.md +++ b/VERSIONING.md @@ -77,7 +77,7 @@ This ensures the SDK remains reliable and accurate for production usage. ### 4.1 Minimum C# Version Changes -Increasing the **minimum targeted .NET/C# framework version** (e.g.,.NET Standard 2.0 → .NET 6.0) is always treated as a **MAJOR** version change. Such a change breaks compilation and runtime compatibility for existing users and therefore constitutes a breaking API change. +Increasing the **minimum targeted .NET/C# framework version** (e.g.,.NET Standard 2.0 → .NET Standard 2.1) is always treated as a **MAJOR** version change. Such a change breaks compilation and runtime compatibility for existing users and therefore constitutes a breaking API change. ### 4.2 Dependency Upgrade Policy From fa74744df18594996f90952e8d86347740e4c437 Mon Sep 17 00:00:00 2001 From: Tamas Juhasz Date: Fri, 28 Nov 2025 13:26:28 +0100 Subject: [PATCH 3/3] Latest fixes for VERSIONING.md --- VERSIONING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VERSIONING.md b/VERSIONING.md index c75bb56..aa45901 100644 --- a/VERSIONING.md +++ b/VERSIONING.md @@ -77,7 +77,7 @@ This ensures the SDK remains reliable and accurate for production usage. ### 4.1 Minimum C# Version Changes -Increasing the **minimum targeted .NET/C# framework version** (e.g.,.NET Standard 2.0 → .NET Standard 2.1) is always treated as a **MAJOR** version change. Such a change breaks compilation and runtime compatibility for existing users and therefore constitutes a breaking API change. +Increasing the **minimum targeted .NET framework version** (e.g.,.NET Standard 2.0 → .NET Standard 2.1) is always treated as a **MAJOR** version change. Such a change may break compilation and runtime compatibility for existing users and therefore constitutes a breaking API change. ### 4.2 Dependency Upgrade Policy