Date: Thu, 09 Sep 1999 20:51:27 +0200 From: Marcel Moolenaar <marcel@scc.nl> To: Sheldon Hearn <sheldonh@uunet.co.za> Cc: Nate Williams <nate@mt.sri.com>, Dmitrij Tejblum <tejblum@arc.hq.cti.ru>, hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions Message-ID: <37D801AF.2B97E791@scc.nl> References: <80742.936899215@axl.noc.iafrica.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sheldon Hearn wrote: > > On Thu, 09 Sep 1999 10:56:05 CST, Nate Williams wrote: > > > Yes, we shouldn't version bump every time someone has a whim, ending > > up with 10 version bumps/week, but neither should we avoid them > > altogether and cause the Linux syndrome of programs refusing to work > > because they have the *wrong* version of glibc2.3 (or whatever).... > > This is starting to sound like what would help is tighter release > management. If changes were held back long enough for a single version > bump to cover multiple changes, the situation would be improved. I'm more tempted to revert to the major/minor versioning. Every change triggers a minor version bump, but only if the library is still backwards compatible with minor version 0 and the same major version. Otherwise a major version bump is required. This only works if the dynamic linker uses a slightly different approach when linking: Linking is performed in such a way that if a program is linked against version x.y of libfoo, then every libfoo with version x.z and z>=y is a valid candidate. If there're more than one candidates, then the linker can pick any of them, but preferable the latest (for example). I don't really mind if we get libraries like libfoo.2.384. It's just like rcs revisions. It gives you information that can help in tracking and solving problems. Heck, you can even add an option to ldconfig to remove all libraries but the latest with a given major version... Ah, well... so much for this brainwave :-) -- Marcel Moolenaar mailto:marcel@scc.nl SCC Internetworking & Databases http://www.scc.nl/ The FreeBSD project mailto:marcel@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37D801AF.2B97E791>