> 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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
