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:[EMAIL PROTECTED]
SCC Internetworking & Databases http://www.scc.nl/
The FreeBSD project mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
