On Tue, Jan 18, 2011 at 10:57:55PM +0100, Matthias Kilian wrote:
> On Tue, Jan 18, 2011 at 12:06:13AM +0100, Pascal Stumpf wrote:
> > > The version you're using in your port is even wrong. A shared library
> > > must have the name libFOO.so.major.minor. I've fixed this (and set
> > > the version to 1.0). Also some cleanups (less patches, allow for
> > > orverriding CC, CXX, CFLAGS, CXXFLAGS etc.).
> > 
> > Ok, sorry. It was utterly stupid to follow the FreeBSD port there. :/
> > But I think we should stick closer to what the authors originally
> > intended, and use $(VERSION_MAJOR).$(VERSION_MINOR) for the library
> > name; the same thing is passed to -soname.
> 
> Sure, you can do this for a new port (like Irrlicht) if you like.
> But version numbers vill very soon diverge between with a projects
> version number and the shared library version number.
> 
> - Many projects treat version nimbers (for both the project *and*
>   shared librararies) based on policy, not on compatility.
> 
> - We ports people don't trust upstream on shared library versions,
>   and there's a good reason for it. We've seen so many upstream
>   minor bumps which contained ABI and API breakage that we prefer
>   to decide ourselves on version numbers of shared libs. Yes, that
>   means that you will have to read the diffs for any update of
>   Irrlicht and to check wether they missed a major bump.
> 
> 
> Really, I had this fun with poppler (IIRC), where ABI changes
> happened without major bumps from upstream.
> 
> Advice of the day: sheared library version numbers are no coupled
> in any way to the projects version numbers.
> 
> Ciao,
>       Kili
> 
> 
Hi,
thanks for the advice. What made me choose to follow the upstream
versioning scheme was the fact that by passing 1.7 to -soname, upstream
seemed indicate that major API changes are only due for ‘minor’
releases. Judging from the changelog, it seems to be true that the third
digit indicates bugfix-only (well, almost …) releases, so the shlib
version suggested in the Makefile reflects that accurately.

So, I’d just leave it alone for now, and if they really do make changes
to the API in a ‘bugfix-only’ release, we can still do our own bump if
it’s needed.

Cheers,
Pascal

Reply via email to