This case of version number update is a little special and was not well-known

before.  A new general rule has been formed:

	When you change a library to *use* a new API of another library
	(which may there only have given need to a minor number crank), you
	must crank the *major*.

The specific scenario that was seen this time was:

	I	libc 16 started without the SHA interface
	II	libskey 0 did obviously not use it
	III	installation of libc 16 and libskey 0
	IV	software installed that uses libskey
	V	libc 16 got SHA added, minor number update
	VI	libskey 0 was changed to use it
	VII	libc was cranked to 17 for other reasons
	VIII	installation of libc 17 and newer libskey 0
	IX	use of the software installed in IV fails!

This is due to the fact that the libskey using software searches for the most
current libskey 0, which uses the SHA interface, and the most current libc 16
which was the old one installed in III, which does not provide SHA, and thus
gets two incompatible libraries linked with it.  Crash!

One could argue that people should install all library versions that is made
available, but that is really not feasible.  One have to recognize that people
may build their systems at arbitrary points in time and then go on to install
software they know work at their lib revision levels.  A later build should
not break this software, that may only be available in binary versions.

1 files changed, 2 insertions, 2 deletions

diff --git a/lib/libskey/shlib_version b/lib/libskey/shlib_version
index b49665a51a9..1edea46de91 100644
--- a/lib/libskey/shlib_version
+++ b/lib/libskey/shlib_version
@@ -1,2 +1,2 @@
-major=0
-minor=7
+major=1
+minor=0