Breaking change support policy

.openpublishing.redirection.json

@@ -0,0 +1,9 @@
+{
+    "redirections": [
+        {
+            "source_path": "Odata-docs/odatalib/v7/using-ut8jsonwriter-for-better-performance.md",
+            "redirect_url": "/odata/odatalib/using-utf8jsonwriter-for-better-performance",
+            "redirect_document_id": true
+        }
+    ]
+}

Odata-docs/TOC.yml

@@ -492,6 +492,8 @@
       href: /odata/resources/support
     - name: Roadmap
       href: /odata/resources/roadmap
+    - name: Supported library version lifecycle
+      href: /odata/resources/version-lifecycle
 - name: Changelog
   items:
     - name: OData lib changes

Odata-docs/odatalib/v7/using-ut8jsonwriter-for-better-performance.md → Odata-docs/odatalib/v7/using-utf8jsonwriter-for-better-performance.md

@@ -55,4 +55,4 @@ You can provide a different `JavaScriptEncoder`. Instead of injecting `DefaultSt
 IStreamBasedJsonWriterFactory factory = new DefaultStreamBasedJsonWriterFactory(JavaScriptEncoder.UnsafeRelaxedJsonEscaping);
 ```
 
-Note that there’s no built-in JavaScriptEncoder that exactly matches the escaping rules of `Microsoft.OData.Core`’s default `JsonWriter`. The raw output of the two writers will be different. But if the client is [standards-compliant](https://www.ietf.org/rfc/rfc4627.txt), this should not be a problem. Nevertheless, this is something you should take into consideration before adopting the new writer. In general, you should not be highly dependent on a particular escaping output because the internal implementation may change from one version of .NET to another (See relevant discussions [here](https://github.com/dotnet/runtime/issues/70419), [here](https://github.com/dotnet/runtime/issues/54193) and [here](https://github.com/dotnet/runtime/issues/1564#issuecomment-504780719)).
+Note that there’s no built-in JavaScriptEncoder that exactly matches the escaping rules of `Microsoft.OData.Core`’s default `JsonWriter`. The raw output of the two writers will be different. But if the client is [standards-compliant](https://www.ietf.org/rfc/rfc4627.txt), this should not be a problem. Nevertheless, this is something you should take into consideration before adopting the new writer. In general, you should not be highly dependent on a particular escaping output because the internal implementation may change from one version of .NET to another (See relevant discussions [here](https://github.com/dotnet/runtime/issues/70419), [here](https://github.com/dotnet/runtime/issues/54193) and [here](https://github.com/dotnet/runtime/issues/1564#issuecomment-504780719)).

Odata-docs/resources/support.md

@@ -16,3 +16,7 @@ Code related issues in the OData .NET libraries can be reported by creating GitH
 ## Questions
 
 General question on library usage should be posted on [stackoverflow](https://stackoverflow.com/questions/tagged/odata) and tagged with `odata` tag.
+
+## Supported library version lifecycle
+
+Resources about the lifecycle of individual library versions can be found [here](./version-lifecycle.md).

Odata-docs/resources/version-lifecycle.md

@@ -0,0 +1,13 @@
+---
+title : "Supported library version lifecycle"
+description: "This section describes what support policy customers can expect for the lifecycle of different OData library versions."
+author: gdebruin
+ms.date: 9/25/2023
+---
+
+# Accidental breaking change releases
+
+Nuget packages published by the [OData nuget profile](https://www.nuget.org/profiles/OData) will have the following actions taken to mitigate the accidental release of a library version that introduces a breaking change:
+1. The package will be marked deprecated.
+2. The deprecated package will specify an alternate version to install (usually `Latest`) with a message indicating what the breaking change was.
+3. The package will be unlisted.