RE: [gtk-list] Re: 1.1 <=> 1.2 not compatible, why not 2.0?

["Rostedt, Steven" <steven rostedt lmco com>]

> This is not correct, minor version numbers change when the library 
> remains binary compatible, major version change when the binary
> compatibility gets broken.
> 
> That allows the dynamic linker to determine whether an application
> linked against a library with a lesser minor number can still be
> used with a library with a bigger minor number, the linker then
> also knows not to use a library with a different *major* number.
> 
> 
	You are right. My mistake. I was fooled by the way that
	it's libgtk-1.2.so not libgtk.so.1.2.
	It's been a while since I worked with building multiple libraries.
	But it does make sense to follow this format, as you said
	for marketing reasons. Actually, it should be libgtk.so.2
	but I think they did this to make it easier to map to 
	the gtk+-1.2 version.  

	If you look at XFree86 they have two different numbers used.
	Version 6 is the libX11.so.6 and there marketing version
	3.3.3.  I wonder if version 4.0 will have libX11.so.7 ?
	because I don't think it is binary compatible.

	This is what I meant as being standard.  I was off on thinking
	that the ld is the same as the versioning. My apologies :(

> The version numbers you talk about are marketing numbers.
> 
> The scheme that gtk uses is absolutely not standard, although I must
> say that if they would have used the major.minor scheme, they would
> be at version 30.1 by now. Although they also might have chosen to
> not bother about the version number in the library in the development
> line.
> 
> And as a final remark, the Linux version numbering scheme has nothing
> to do with shared library versioning! Except that the gtk people 
> wanted to try using this scheme to indicate the development line.
> 
> Marc.
> 
> 
	Marc,
	Thank you for the correction.

	Steve.