Date: Thu, 09 Nov 1995 21:05:44 -0800 From: John Polstra <jdp@polstra.com> To: Joe Greco <jgreco@brasil.moneng.mei.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Kerb Encr Telnet!! I found the problem! Message-ID: <199511100505.VAA01389@austin.polstra.com> In-Reply-To: Your message of "Thu, 09 Nov 1995 22:42:17 CST." <199511100442.WAA23781@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I think the right solution would be to _religiously_ follow the rule > > that shared library minor version numbers get incremented on _every_ new > > "release". Whether "release" means RELEASE or SNAPshot is probably a > > matter of judgement. To be perfectly safe, the minor number would have > > to increase every time a library changed in any way whatsoever. > > I would argue that that is needlessly strict. You don't WANT to update the > minor version numbers every RELEASE or SNAP, unless there is a difference > that would require it. A version number change is intended to convey the > fact that the available library interface is somehow different. Sorry, I don't agree with this particular statement. A change in the MAJOR version number conveys the fact that the interface is different. But a change in the minor version number simply indicates a newer implementation of the same interface (or at least one that is backwards compatible). This distinction is explicit not only in the SunOS/SVR4 documentation, but also in the way that shared library dependencies are resolved in executables and in other shared libraries. When searching for a shared library to satisfy a dependency, both ld and ld.so search for an exact match on only the library name and the major version number. But an exact match is not required for the minor version number; it is required only that the minor version of the library be the highest available, and at least as great as the minor version specified in the dependency. This is a crucial distinction. Major version numbers represent changes in functionality, while minor versions simply represent newer implementations. > If I add functionality that requires external support, or add new > functionality that adds to or changes the library interface, that > SHOULD be a version bump. Yes -- it should be a bump in the MAJOR version number. > So when libtelnet was Kerberized, the numbers for both > regular and Kerberized should have been bumped (in my mind). Yes, but again, in this case the major version numbers should have been bumped. > This is, of course, a subject that merits debate :-) No argument there. We all share the ultimate goal of making things as foolproof as reasonably possible. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511100505.VAA01389>