> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
