Am 22.01.2012 um 01:29 schrieb Dominik Reichardt
> > > Am 22.01.2012 um 01:22 schrieb Ryan Schmidt <[email protected]>: > >> >> On Jan 21, 2012, at 17:50, Dominik Reichardt wrote: >> >>> Ryan Schmidt wrote: >>> >>>> On Jan 21, 2012, at 13:58, Dominik Reichardt wrote: >>>> >>>>> Don't all the dependants on libSDL need a version bump too? Especially >>>>> the SDL satellite libs libSDL_net, libSDL_ttf, libSDL_mixer, etc... >>>> >>>> Why do you think they do? Did the library version change? >>> >>> Yes libSDL was updated to 1.2.15 from 1.2.14 yesterday (a much wanted >>> release as it fixes fullscreen for SDL apps on Lion). I *think* the >>> dependants need an update too but I'm not 100% sure whether that's really >>> needed. That's why I asked ;) >> >> Right, that's a minor version update. If the libsdl developers are following >> sensible version numbering practices, 1.2.15 should be fully >> backward-compatible with 1.2.14. Let's have a look: >> >> $ port -q installed libsdl >> libsdl @1.2.14_9+universal+x11 (active) >> $ otool -L /opt/local/lib/libSDL.dylib | head -n 2 >> /opt/local/lib/libSDL.dylib: >> /opt/local/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current >> version 12.3.0) >> $ sudo port -u upgrade libsdl >> [snip] >> $ port -q installed libsdl >> libsdl @1.2.15_0+universal+x11 (active) >> $ otool -L /opt/local/lib/libSDL.dylib | head -n 2 >> /opt/local/lib/libSDL.dylib: >> /opt/local/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current >> version 12.4.0) >> >> As you see, the compatibility version is the same, so no revbump is needed. >> Now, if libsdl had been updated to 1.3, the library version probably would >> have changed, since 1.3 has been in development forever and we already know >> it's drastically different from the 1.2 series, so that would indeed have >> required a revbump of all ports using it. > > Thanks for clarifying, I understand this now. > > As for libsdl 1.3, it seems the verdict is that when it gets rekeased it's > gonna be a bump to version 2.0 along with a renaming scheme (e.g. > libsdl2.dylib). But nothing in stone yet, not to mention no timeline for it > yet... Ok, this just went live in SDL mercurial. No more SDL 1.3. It's now SDL 2. This will mean that SDL 1.2.x and SDL development no longer block each other on macports. Downside is that projects that use either SDL need to be configured for which SDL they should be. Not to mention that they need fixes to make use of SDL 2 instead of SDL 1.3. Also the 1.2.x compatibility layer has been ripped out -> more problems for projects which took the easy way to port to SDL 1.3... Dom _______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
