From 09460734065c568be283cd0cccdb6c686d979fe1 Mon Sep 17 00:00:00 2001
From: Ian Barwick <barwick@gmail.com>
Date: Thu, 23 May 2019 09:07:02 +0900
Subject: [PATCH] doc: remove references to putative 4.3.1 release

The changes listed will be part of the upcoming 4.4 release.
---
 HISTORY                         |  8 ---
 doc/appendix-release-notes.sgml | 93 ---------------------------------
 2 files changed, 101 deletions(-)

diff --git a/HISTORY b/HISTORY
index f21e1eed..441adcaf 100644
--- a/HISTORY
+++ b/HISTORY
@@ -1,11 +1,3 @@
-4.3.1   2019-??-??
-        repmgr: ensure BDR2-specific functionality cannot be used on
-          BDR3 and later (Ian)
-        repmgr: improve --dry-run behaviour in barman mode (Ian)
-        repmgr: fix data directory permissions issue in barman mode where
-          an existing directory is being overwritten (Ian)
-
-4.3     2019-04-02
         repmgr: add "daemon (start|stop)" command; GitHub #528 (Ian)
         repmgr: add --version-number command line option (Ian)
         repmgr: add --compact option to "cluster show"; GitHub #521 (Ian)
diff --git a/doc/appendix-release-notes.sgml b/doc/appendix-release-notes.sgml
index 4931b0c7..707ab0a5 100644
--- a/doc/appendix-release-notes.sgml
+++ b/doc/appendix-release-notes.sgml
@@ -15,99 +15,6 @@
     See also: <xref linkend="upgrading-repmgr">
   </para>
 
-  <sect1 id="release-4.3.1">
-    <title>Release 4.3.1</title>
-    <para><emphasis>???</emphasis></para>
-
-    <para>
-      &repmgr; 4.3.1 will be a minor release. Note that the changes listed here
-      are listed for inclusion in a potential 4.3.1 release, but it is not yet
-      certain whether this will take place, in which case all changes will
-      be folded into the &repmgr; 4.4 release.
-    </para>
-
-    <sect2>
-      <title>repmgr client enhancements</title>
-      <para>
-        <itemizedlist>
-          <listitem>
-            <para>
-              &repmgr;: when executing <link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>,
-              if <option>--siblings-follow</option> is not supplied, list all nodes which repmgr considers
-              to be siblings (this will include the witness server, if in use), and
-              which will remain attached to the old primary.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              &repmgr;: when executing <link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>,
-              ignore nodes which are unreachable and marked as inactive.
-              Previously it would abort if any node was unreachable,
-              as that means it was unable to check if repmgrd is running.
-            </para>
-            <para>
-              However if the node has been marked as inactive in the repmgr metadata, it's
-              reasonable to assume the node is no longer part of the replication cluster
-              and does not need to be checked.
-            </para>
-          </listitem>
-
-        </itemizedlist>
-      </para>
-    </sect2>
-
-    <sect2>
-      <title>Bug fixes</title>
-      <para>
-        <itemizedlist>
-          <listitem>
-            <para>
-              Ensure BDR2-specific functionality cannot be used on BDR3 and later.
-            </para>
-            <para>
-              The BDR support present in &repmgr; is for specific BDR2 use cases.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              &repmgr;: when executing <link linkend="repmgr-standby-clone"><command>repmgr standby clone</command></link>
-              in <option>--dry-run</option> mode, ensure provision of the <option>--force</option> option
-              does not result in an existing data directory being modified in any way.
-            </para>
-          </listitem>
-
-          <listitem>
-            <para>
-              &repmgr;: when executing <link linkend="repmgr-primary-register"><command>repmgr primary register</command></link>
-              with the <option>--force</option> option, if another primary record exists but the associated node is
-              unreachable (or running as a standby), set that node's record to inactive to enable the current node
-              to be registered as a primary.
-            </para>
-          </listitem>
-
-		  <listitem>
-			<para>
-              &repmgr;: when executing <link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>,
-              don't abort if one or more nodes are not reachable <emphasis>and</emphasis>
-			  they are marked as inactive.
-			</para>
-		  </listitem>
-
-		  <listitem>
-			<para>
-              &repmgrd;: fix memory leak which occurs while the monitored PostgreSQL node is <emphasis>not</emphasis>
-              running.
-            </para>
-          </listitem>
-
-        </itemizedlist>
-	  </para>
-    </sect2>
-
-  </sect1>
-
   <sect1 id="release-4.3">
     <title>Release 4.3</title>
     <para><emphasis>Tue April 2, 2019</emphasis></para>