Date: Fri, 10 Sep 1999 00:29:55 +0400 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: nate@mt.sri.com (Nate Williams) Cc: Marcel Moolenaar <marcel@scc.nl>, hackers@FreeBSD.ORG Subject: Re: 32+ signals and library versions Message-ID: <199909092029.AAA21626@arc.hq.cti.ru> In-Reply-To: Your message of "Thu, 09 Sep 1999 10:56:05 MDT." <199909091656.KAA03831@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> For what it's worth, I agree with Marcel. Version bumps should be > discouraged, but not totally avoided. What is the reason to not avoid the version bump? > Carrying around old libraries > with older version numbers is *hardly* a burden for the users, and those > folks who are running old versions of FreeBSD will not be effected at > all since they will continue to keep the old libraries around. Version bumps are problem for vendors and users of binary-only products (vendors usually request users to install old libraries), users of obsolete versions of FreeBSD (who cannot get a binary linked with their libc, and has no chances to make them running), and people who maintain a lot of FreeBSD boxes running different versions of FreeBSD, who will have to build their own binaries several times. I hate old libraries because they are binary-only programs without a maintainer. Old libraries are difficult if not impossible to fix or improve. For (quite benign) example, look at PR bin/13623. > 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).... If we do it right, we will not suffer from the syndrome. If Linux is broken - throw it away ;-) It goes without saying that changes in existing interfaces must include a version bump. Conclusion: don't change any existing interface. This rule is followed in the kernel, which survived conversion of off_t from 32 to 64 bit. It can be followed in libc. Dima 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?199909092029.AAA21626>