Automate the maintenance of SO_MINOR_VERSION for our shared libraries.

Up to now we've manually adjusted these numbers in several different
Makefiles at the start of each development cycle.  While that's not
much work, it's easily forgotten, so let's get rid of it by setting
the SO_MINOR_VERSION values directly from $(MAJORVERSION).

In the case of libpq, this dev cycle's value of SO_MINOR_VERSION happens
to be "10" anyway, so this switch is transparent.  For ecpg's shared
libraries, this will result in skipping one or two minor version numbers
between v9.6 and v10, which seems like no big problem; and it was a bit
inconsistent that they didn't have equal minor version numbers anyway.

Discussion: <21969.1471287988@sss.pgh.pa.us>

Author: tglsfdc

src/interfaces/ecpg/compatlib/Makefile

@@ -16,7 +16,7 @@ include $(top_builddir)/src/Makefile.global
 PGFILEDESC = "ECPG compat - compatibility library for ECPG"
 NAME= ecpg_compat
 SO_MAJOR_VERSION= 3
-SO_MINOR_VERSION= 9
+SO_MINOR_VERSION= $(MAJORVERSION)
 
 override CPPFLAGS := -I../include -I$(top_srcdir)/src/interfaces/ecpg/include \
 	-I$(libpq_srcdir) -DFRONTEND $(CPPFLAGS)

src/interfaces/ecpg/ecpglib/Makefile

@@ -16,7 +16,7 @@ include $(top_builddir)/src/Makefile.global
 PGFILEDESC = "ECPG - embedded SQL in C"
 NAME= ecpg
 SO_MAJOR_VERSION= 6
-SO_MINOR_VERSION= 9
+SO_MINOR_VERSION= $(MAJORVERSION)
 
 override CPPFLAGS := -I../include -I$(top_srcdir)/src/interfaces/ecpg/include \
 	-I$(libpq_srcdir) -I$(top_builddir)/src/port -DFRONTEND $(CPPFLAGS)

src/interfaces/ecpg/pgtypeslib/Makefile

@@ -16,7 +16,7 @@ include $(top_builddir)/src/Makefile.global
 PGFILEDESC = "pgtypes - library for data type mapping"
 NAME= pgtypes
 SO_MAJOR_VERSION= 3
-SO_MINOR_VERSION= 8
+SO_MINOR_VERSION= $(MAJORVERSION)
 
 override CPPFLAGS := -I../include -I$(top_srcdir)/src/interfaces/ecpg/include \
 	-DFRONTEND $(CPPFLAGS)

src/interfaces/libpq/Makefile

@@ -17,7 +17,7 @@ include $(top_builddir)/src/Makefile.global
 # shared library parameters
 NAME= pq
 SO_MAJOR_VERSION= 5
-SO_MINOR_VERSION= 10
+SO_MINOR_VERSION= $(MAJORVERSION)
 
 override CPPFLAGS :=  -DFRONTEND -DUNSAFE_STAT_OK -I$(srcdir) $(CPPFLAGS) -I$(top_builddir)/src/port -I$(top_srcdir)/src/port
 ifneq ($(PORTNAME), win32)

src/tools/RELEASE_CHANGES

@@ -73,19 +73,12 @@ Starting a New Development Cycle
 	  for example,
 		git push origin master:refs/heads/REL9_2_STABLE
 
+* Add new branch's name to list in src/tools/git_changelog
+
 * Increment the major version number in src/tools/version_stamp.pl
 
 * Run "src/tools/version_stamp.pl devel", then run autoconf
 
-* Add version tag to src/tools/git_changelog
-
-* Bump minor library versions, major if appropriate (see below)
-  o Look for SO_MINOR_VERSION macros in
-	src/interfaces/ecpg/compatlib/Makefile
-	src/interfaces/ecpg/ecpglib/Makefile
-	src/interfaces/ecpg/pgtypeslib/Makefile
-	src/interfaces/libpq/Makefile
-
 
 Creating Back-Branch Release Notes
 ==================================
@@ -139,8 +132,7 @@ function which would give the new field a suitable default value.
 Adding a new function should NOT force an increase in the major version
 number. (Packagers will see the standard minor number update and install
 the new library.)  When the major version is increased all applications
-which link to the library MUST be recompiled - this is not desirable. When
-the major version is updated the minor version gets reset.
+which link to the library MUST be recompiled - this is not desirable.
 
 Minor Version
 =============
@@ -150,9 +142,19 @@ the library has changed, typically a change in source code between releases
 would mean an increase in the minor version number so long as it does not
 require a major version increase.
 
-Given that we make at least minor changes to our libraries in every major
-PostgreSQL version, we always bump all minor library version numbers at the
-start of each development cycle as a matter of policy.
+Given that we make at least some changes to our libraries in every major
+PostgreSQL version, we always bump all minor library version numbers in
+each development cycle as a matter of policy.  This is currently mechanized
+by referencing the MAJORVERSION make macro in the value of SO_MINOR_VERSION
+for each shared library.  As of v10, SO_MINOR_VERSION is simply equal to
+MAJORVERSION in all cases.  If we ever make an incompatible break in a
+library's API, forcing a major version bump, we could continue to increase
+SO_MINOR_VERSION (thus, perhaps, going from libpq.so.5.12 to libpq.so.6.13),
+or we could reset SO_MINOR_VERSION to zero, using makefile code along the
+lines of
+	SO_MINOR_VERSION= $(shell expr $(MAJORVERSION) - 13)
+so that the number continues to increase automatically in later branches.
+For now, that complication is not necessary.
 
 Minimizing Changes
 ==================