Merge pull request #3231 from EnterpriseDB/release/2022-10-06c

Release: 2022-10-06c

product_docs/docs/biganimal/release/using_cluster/02_connecting_your_cluster/index.mdx

@@ -83,6 +83,11 @@ SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, co
      Driver={PostgreSQL};Server=xxxxxxxxx.xxxxx.biganimal.io;Port=5432;Database=myDataBase;Uid=edb_admin;Pwd=$PWD;sslrootcert=C:\\ssl\\ca-certificate.pem;sslmode=verify-full;
      ```
 
+## Connect your cluster to EDB's migration tools
+
+To connect to your cluster to EDB's migration tools, see [Migrating databases to BigAnimal](/biganimal/latest/migration/).
+
+
 ## Connect to your cluster using pgAdmin
 
 To connect to your BigAnimal cluster from [pgAdmin](https://www.pgadmin.org/docs/), you need to enter your cluster values into pgAdmin. Keep BigAnimal and pgAdmin open to copy and paste the values. 

product_docs/docs/pgd/3.7/bdr/upgrades.mdx → product_docs/docs/pgd/3.7/bdr/upgrades/index.mdx

@@ -2,7 +2,6 @@
 navTitle: Upgrades
 title: Application Schema Upgrades
 originalFilePath: upgrades.md
-
 ---
 
 In this chapter we discuss upgrading software on a EDB Postgres Distributed cluster and how

product_docs/docs/pgd/3.7/bdr/upgrades/supported_paths.mdx

@@ -0,0 +1,13 @@
+---
+title: Supported BDR upgrade paths
+---
+### Upgrading from version 3.6 to version 3.7
+
+We recommend you upgrade your cluster to the latest version of 3.6 before upgrading your cluster to 3.7.  You will then be able to upgrade to a version of 3.7 released on the same date or later. 
+
+
+### Upgrading within version 3.7
+
+BDR 3.7 does not follow semantic versioning. Instead, it uses 2 position majors similar to PostgreSQL releases prior to version 10 (e.g. 9.6).  BDR 3.7 also considered releases prior to 3.7.9 as beta releases and they could include breaking changes.  BDR 3.7.9 was declared a Long Term Sppoort version under the previous versioning nomenclature.  All releses 3.7.9 and later maintain backward compatibility allowing upgrades to later versions.
+
+

product_docs/docs/pgd/4/other_considerations.mdx

@@ -6,7 +6,7 @@ Review these other considerations when planning your deployment.
 
 ## Deployment and sizing considerations
 
-For production deployments, EDB recommends a minimum of eight cores for each Postgres data node and each logical standby. Witness nodes don't participate in the data replication operation and don't have to meet this requirement. Always size logical standbys exactly like the data nodes to avoid performance degradations in case of a node promotion. In production deployments, HARP proxy nodes require a minimum of four cores each. EDB recommends detailed benchmarking of performance requirements, working with EDB’s Professional Services team.
+For production deployments, EDB recommends a minimum of four cores for each Postgres data node and each logical standby. Witness nodes don't participate in the data replication operation and don't have to meet this requirement. Always size logical standbys exactly like the data nodes to avoid performance degradations in case of a node promotion. In production deployments, HARP proxy nodes require a minimum of two cores each. EDB recommends detailed benchmarking based on your performance requirements to determine the correct sizing for your environment.  EDB’s Professional Services team is available to assist, if needed.
 
 For development purposes, don't assign Postgres data nodes fewer than two cores. The sizing of Barman nodes depends on the database size and the data change rate.
 

product_docs/docs/pgd/4/upgrades/upgrade_paths.mdx

@@ -2,12 +2,31 @@
 title: Supported BDR upgrade paths
 ---
 
-| 3.7.13.1 | 3.7.14 | 3.7.15 | 3.7.16 | 4.0.0 and later | Target BDR version |
-|----------|--------|--------|--------|-----------------|--------------------|
-|          |        | X      | X      | X               | 4.2.0              |
-|          |        | X      | X      | X               | 4.1.1              |
-|          |        | X      | X      | X               | 4.1.0              |
-|          |        | X      |        | X               | 4.0.2              |
-|          | X      |        |        | X               | 4.0.1              |
-| X        |        |        |        |                 | 4.0.0              |
+## Upgrading from version 3.6 to version 4
+
+Currently there are no direct upgrade paths from 3.6 to 4.  You must first upgrade your cluster to 3.7 before upgrading to 4.  See [Upgrading from 3.6](/pgd/3.7/bdr/upgrades/supported_paths/#upgrading-from-version-36) in the 3.7 documentation for more information.
+
+## Upgrading from version 3.7 to version 4
+
+Currently it is recommended that you are using 3.7.15 or later before upgrading to 4. See [Upgrading within from 3.7](/pgd/3.7/bdr/updrades/supported_paths/#upgrading-within-version-37) in the 3.7 documentation for more information.  After upgrading to 3.7.15 or later the following combinations are allowed
+
+| 3.7.15 | 3.7.16 | 3.7.17 | Target BDR version |
+|--------|--------|--------|--------------------|
+| X      | X      | X      | 4.2.0              |
+| X      | X      |        | 4.1.1              |
+| X      | X      |        | 4.1.0              |
+| X      |        |        | 4.0.2              |
+
+## Upgrading within version 4
+
+Beginning with version 4, EDB Postgres Distributed has adopted semantic versioning. All changes within the same major will be backward compatible lowering the risk when upgrading and allowing you to choose any later minor or patch release as the upgrade target. 
+
+| 4.0.0 | 4.0.1 | 4.0.2 | 4.1.0 | 4.1.1 | Target BDR version |
+|-------|-------|-------|--------|------|--------------------|
+| X     | X     | X     | X      | X    | 4.2.0              |
+| X     | X     | X     | X      |      | 4.1.1              |
+| X     | X     | X     |        |      | 4.1.0              |
+| X     | X     |       |        |      | 4.0.2              |
+| X     |       |       |        |      | 4.0.1              |
+