Move 6.0 to "out of support" and some general minor changes for 9.0 (#…

…378)

conceptual/EFCore.PG/release-notes/9.0.md

@@ -1,15 +1,12 @@
 # 9.0 Release Notes
 
-Npgsql.EntityFrameworkCore.PostgreSQL version 9.0 is under development; previews are available on [nuget.org](https://www.nuget.org/packages/Npgsql.EntityFrameworkCore.PostgreSQL).
-
-> [!NOTE]
-> The following release notes and breaking changes are partial. More will be added nearer to the 9.0 final release.
+Npgsql.EntityFrameworkCore.PostgreSQL version 9.0 is out and available on [nuget.org](https://www.nuget.org/packages/Npgsql.EntityFrameworkCore.PostgreSQL).
 
 ## Improved, unified configuration experience
 
 The Npgsql EF provider is built on top of the lower-level Npgsql ADO.NET provider; the configuration interface between these two layers was less than ideal, and configuration been more difficult than it should have been. For version 9.0, the configuration experience has been considerably improved.
 
-Since version 7, the Npgsql ADO.NET provider has been moving to [NpgsqlDataSource](../../Npgsql/basic-usage.md#data-source) as the preferred way of configuration connections and obtaining them. At the EF level, it has been possible to pass an NpgsqlDataSource instance to `UseNpgsql()`; but this required that the user separately configure a data source and manage it. In addition, features such as  plugins and enums require support from both the EF and ADO.NET layers, forcing users to perform multiple setup actions at the different layers.
+Since version 7, the Npgsql ADO.NET provider has been moving to [NpgsqlDataSource](../../Npgsql/basic-usage.md#data-source) as the preferred way of configuring connections and obtaining them. At the EF level, it has been possible to pass an NpgsqlDataSource instance to `UseNpgsql()`; but this required that the user separately configure a data source and manage it. In addition, features such as plugins and enums require support from both the EF and ADO.NET layers, forcing users to perform multiple setup actions at the different layers.
 
 With version 9, `UseNpgsql()` becomes a single point for configuration, for both the EF and ADO.NET levels. EF can now internally set up an NpgsqlDataSource, automatically applying all the necessary configuration to it, and also exposes an API to allow users to apply arbitrary configuration to it as well:
 

conceptual/EFCore.PG/toc.yml

@@ -2,16 +2,16 @@
   href: index.md
 - name: Release notes
   items:
-  - name: "9.0 (prerelease)"
+  - name: "9.0"
     href: release-notes/9.0.md
   - name: "8.0"
     href: release-notes/8.0.md
-  - name: "6.0"
-    href: release-notes/6.0.md
   - name: Out of support
     items:
     - name: "7.0"
       href: release-notes/7.0.md
+    - name: "6.0"
+      href: release-notes/6.0.md
     - name: "5.0"
       href: release-notes/5.0.md
     - name: "3.1"

conceptual/Npgsql/release-notes/9.0.md

@@ -1,9 +1,9 @@
 # Npgsql 9.0 Release Notes
 
-Npgsql version 9.0 will be released together with .NET 9 and will be available on nuget. The full list of issues for this release is [available here](https://github.com/npgsql/npgsql/milestone/109?closed=1).
+Npgsql.EntityFrameworkCore.PostgreSQL version 9.0 is out and available on [nuget.org](https://www.nuget.org/packages/Npgsql).
 
 > [!NOTE]
-> We're considering to start dropping support for synchronous API (`NpgsqlConnection.Open`, `NpgsqlCommand.ExecuteNonQuery`, etc) starting with Npgsql 10.0. The current plan is to deprecate the API by throwing a runtime exception by default (with a switch to re-enable synchronous I/O) for Npgsql 10.0, while completely removing it for Npgsql 11.0. This is in line with ASP.NET Core and .NET runtime in general, which are moving in the direction of async I/O only (for example, `System.IO.Pipelines` doesn't have synchronous I/O). If you have any questions or want to share you experience/issues with async I/O, please feel free to post in the [issue](https://github.com/npgsql/npgsql/issues/5865).
+> We're considering to start dropping support for synchronous APIs (`NpgsqlConnection.Open`, `NpgsqlCommand.ExecuteNonQuery`, etc.) starting with Npgsql 10.0. The current plan is to deprecate the API by throwing a runtime exception by default (with a switch to re-enable synchronous I/O) for Npgsql 10.0, while possibly completely removing it for Npgsql 11.0. This is in line with ASP.NET Core and .NET runtime in general, which are moving in the direction of async I/O only (for example, `System.IO.Pipelines` doesn't have synchronous I/O). If you have any questions or want to share you experience/issues with async I/O, please feel free to post in the [issue](https://github.com/npgsql/npgsql/issues/5865).
 
 ## Tracing improvements
 

conceptual/Npgsql/toc.yml

@@ -6,12 +6,12 @@
     href: release-notes/9.0.md
   - name: "8.0"
     href: release-notes/8.0.md
-  - name: "6.0"
-    href: release-notes/6.0.md
   - name: Out of support
     items:
     - name: "7.0"
       href: release-notes/7.0.md
+    - name: "6.0"
+      href: release-notes/6.0.md
     - name: "5.0"
       href: release-notes/5.0.md
     - name: "4.1"
@@ -89,4 +89,4 @@
   - name: Tests
     href: dev/tests.md
   - name: Type representations
-    href: dev/type-representations.md
+    href: dev/type-representations.md