From 6fc4dde02a6797a224a06b4e598cb5cd042c2441 Mon Sep 17 00:00:00 2001 From: obrien Date: Mon, 9 Dec 1996 11:18:52 +0000 Subject: [PATCH] Added speal about shlib version numbers. Implicitly requested via -ports email by: Satoshi --- share/doc/handbook/policies.sgml | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) diff --git a/share/doc/handbook/policies.sgml b/share/doc/handbook/policies.sgml index 4eabf0eac5a2..b5d9f5617a3c 100644 --- a/share/doc/handbook/policies.sgml +++ b/share/doc/handbook/policies.sgml @@ -1,4 +1,4 @@ - + Source Tree Guidelines and Policies @@ -137,3 +137,30 @@ should be added and it should states things like: Where to send patches back to the original authors Perhaps an overview of the FreeBSD-specific changes that have been made. + +Shared libraries + + +

Contributed by &a.asami; and &a.obrien;. + 9 December 1996.

+ +

If you are adding shlib support to a port or other piece of software that + doesn't have one, the version numbers should follow the following rules, + which in general have nothing to do with the release version of the + software. +

The three principles of shared library building (tm) are: + + + Start from 1.0 + If there is a backwards-compatible change, bump minor number + If there is an incompatible change, bump major number + + +

For instance, added functions and bugfixes are (2). Deleted functions, + changed function call syntax type changes fall in (3). + +

Stick to version numbers of the form major.minor (x.y). Our dynamic + linker does not handle version numbers of the form x.y.z well. Any + version number after the ``y'' is ignored, and cannot be used to + differentiate between two different shared library versions.