On Tue, 26 Jun 2007 15:17:24 -0700 Wes wrote: WH> There are vendors that try to be more backwards compatible than we do, WH> and I hear from them all the time that their users complain about our WH> .so suffix numbers jumping upward because it breaks older application WH> builds. (and no, they don't want to rebuild as their applications WH> aren't likely to be affected by new things).
Then they should provide 'compat' libraries. That's why there are versions in the library names - so multiple versions can be installed. It's also an artifact of our policy on supporting multiple old releases for so long. If we were willing to have a much more restrictive policy on changes allows in released branches, we wouldn't need the forced version jump on major releases. WH> Sigh. Really, I hate to say it, we should be using different libtool WH> versions per library. Indeed we should. WH> That'll only solve some of the problems though. When the oldest WH> structures known to the project haven't changed, then an application WH> certainly won't be affected by a struct update to something new and WH> fancy that they're not using. Yes. And if we imposed a more restrictive policy on libnetsnmp, we could probably get away without the forced jumps between releases (at the expense of maybe having to _not_ be able to fix some bugs in older releases, and require users to upgrade). ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
