> > 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?
Because if you don't have the latest/greatest library (old machines), newer programs that are compiled against the latest/greatest will refuse to work, even though the user is using the correct 'version' of the library. As Marcel pointed out, the violates POLA. If you are running the wrong version of the library, the system should complain about it. Version bumps aren't the spawn of the devil, but they should be avoided else we end up with libc.so.234456, like in NetBSD. :( > > 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), Why is this a problem? It's the *exact* same problem as faced above, except that there is no indication there is a problem because the version number is correct. > users of obsolete versions of FreeBSD (who cannot get a binary linked > with their libc, and has no chances to make them running) Specious argument. FreeBSD has *always* provided backward compatability libraries. We've still got compatability libraries from FreeBSD 1. > and people > who maintain a lot of FreeBSD boxes running different versions of > FreeBSD, who will have to build their own binaries several times. They'll have to do this anyway, unless they build it on the 'oldest' box available, at which point the binary will work on all of the newer boxes anyway because of the compatability libraries. > 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. Old binaries are binary-only programs w/out a maintainer as well. This is just pure silliness. If you want a 'fix', then rebuild/relink your application. This is trivial to do. > It goes without saying that changes in existing interfaces must include > a version bump. Conclusion: don't change any existing interface. Wrong, then the kernel and/or source ends up being so bloated with 'old interfaces' for *NO GOOD REASON* that the software becomes un-maintainable. Forward progress means that sometimes you change existing interfaces when the pain in doing so is so small to be inconsequential, which is the case with shlibs. Nate To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
