On Fri, 18 Aug 2006 14:41:32 +0100 Dave wrote: DS> I must admit that I'm drawn to Wes' original position - a patches DS> branch shouldn't include incompatible changes, so ought to continue DS> with the same library number throughout.
I agree too. The hardline position would be that a bug that could only be fixed in such a manner that binary compatibility simply wouldn't be fixed, and we would simply tell everyone to upgrade. And hope that the fix isn't for a security issue, because you know it's not easy to get everyone to upgrade. DS> [...] But just allowing one single library change within a DS> given patches branch feels extremely shortsighted. How would we DS> decide when to allow that one change? And what we would do when we DS> wanted to make another (possibly more vital) change in the same line. If you s/wanted/needed/, then that's exactly my point. The idea isn't to open up old lines for whimsical changes, but for real bugfixes that break binary compatibility. A good example would be having to change a structure member from an int to size_t, which would be binary incompatible on a 64bit system. DS> Now I'm no expert on library version management, but is it true that DS> we're restricted to a single version number? I'm sure that I've seen DS> shared libraries named something like DS> DS> libwombat.so.1 DS> libwombat.so.1.3 DS> libwombat.so.1.3.6.1 DS> DS> Isn't that exactly the sort of approach needed for this situation - DS> later libraries on a given patch branch should be "mostly compatible" DS> with earlier ones? No. The additional identifiers allow for an app to require a library which, for example, has addition functionality (say a new function call). We can do that with the existing scheme. But the first number must be changed if any API has changed (eg param added/dropped), been removed, or a structure size has changed. We don't change the API, so it's really the structure size that's the potential bug-a-boo. Such problems should be rare in patches branches, but that doesn't mean it won't happen. Since it's already happened once, I'm not optimistic it will never happen again. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
