Dmitrij Tejblum wrote:
>
> Marcel Moolenaar wrote:
> > > I suggest to try to avoid the version bump. NetBSD-like way to do it:
> > > Give new implementations another names in object files, so that they
> > > don't conflict with old implementations, and preserve old
> > > implementations in the library too. To make the compiler generate calls
> > > to new implementations, one can add appropriate #define s in .h files.
> > > For GCC, __asm__ attribute also can be used.
>
> No, when new functions are added into the library, and binaries linked
> with the old library will continue to work with new library, version bump
> is not required.
>
> This is a standard rule. It was also recently discussed on -committers
> on Aug 20 in the thread
> Re: cvs commit: src/include histedit.h src/lib/libedit Makefile editline.3 el.c el.h
In that discussion it has been said that datatype changes require a version
change. Now you're telling me that we should implement datatype changes as
new functions which consequently don't require a version change. So now the
policy is "version bump avoidance at all cost"?
Can someone tell me why we have the freakin' version numbers?
> > How else
> > do I know wich version x library has the new implementations (besides the
> > larger one :-)?
>
> Linker knows it. If some function ("new implementation") is missing, linker print
> an error message. This is all you need.
I strongly disagree. Spitting "unresolved references" is *not* a way to
tell the user that he doesn't have the right libraries.
Now I know why Bruce doesn't believe in version numbers. They're probably
the most misused objects in the universe :-(
--
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
