Date: Mon, 9 Dec 1996 00:24:31 -0800 (PST) From: asami@freebsd.org (Satoshi Asami) To: thomas@ghpc8.ihf.rwth-aachen.de Cc: CVS-committers@freefall.freebsd.org, cvs-all@freefall.freebsd.org, cvs-ports@freefall.freebsd.org Subject: Re: cvs commit: ports/graphics/ImageMagick/pkg PLIST Message-ID: <199612090824.AAA11710@silvia.HIP.Berkeley.EDU> In-Reply-To: <199612090709.IAA06055@ghpc6.ihf.rwth-aachen.de> (message from Thomas Gellekum on Mon, 9 Dec 1996 08:09:01 %2B0100 (MET))
next in thread | previous in thread | raw e-mail | index | archive | help
* > BTW, is it really
* > necessary to keep the shared library number in sync with the
* > release version?
*
* Probably not, as long as you use the new binaries (display, animate,
* mogrify, ...) with the corresponding library. I'll take a look at the
* Imakefiles tonight.
Well, if the port comes with shlib version numbers configured that
way, that's ok.
However (this is more of a general comment to porters, not you in
particular), if you are adding shlib support to a port that doesn't
have one, the version numbers should follow our rules, which in
general have nothing to do with the release version of the software.
The three principles of shared library building (tm) is:
(1) Start from 1.0
(2) If there is a backwards-compatible change, bump minor number
(3) If there is an incompatible change, bump major number
(I'm not sure how x.y.z numbers are handled by our linker, though.)
For instance, added functions and bugfixes are (2). Deleted
functions, changed function call syntax type changes fall in (3).
Satoshi
P.S. I thought someone added this to the handbook, but I can't find
it. If it's not there yet, it should go in "Source Tree
Guidelines and Policies". (The above rule applies not only to
ports.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612090824.AAA11710>