>>>>> On Thu, 2 Feb 2006 17:22:07 -0500, Robert Story <[EMAIL PROTECTED]> said:
Robert> So, we've done the 'right' thing with respect to libtool Robert> versioning now, but we seem to have painted ourselves into a Robert> corner. Starting with some background material, here are the Robert> comments regarding updating the versions from Makefile.top: Ug. Remind me again who convinced me this was a good thing to do? The libtool versioning system has *so* many problems. multiple branch support does appear to be one of the worst. sigh... Fundamentally, there are a number of important poitns to think about with this though, just to be clear: 1) the versioning only is a problem when public structures/etc are changed. Generally we shouldn't be changing these for branch releases. This, of course, poses a bit more of a problem when it comes down to the fact that we don't exactly define what is public and what is not. However, I wouldn't worry about modifying structures in the agent mib modules as much as the base snmp_session struct, for example. 2) we do need to be realistic about when we decide to bump things and whether it's ok or not to change major versions. Lets not swing to the other end of the pendulum. The result of this is likely we'll need to "discuss" what should be done during the problem times. That's probably a good thing anyway. Robert> It has just become an issue (see the thread net-snmpd 5.3.0.1 Robert> crashes in disman mib), so we need to come up with a solution Robert> before 5.4 goes out. Granted, in this particular case 5.2.x Robert> is only affected on big-endian systems that have configure Robert> with --enable-mfd-rewrites, but it could have been (or could Robert> be) an important security issue. That's sort of my point with respect to #2. How many systems is this likely to affect? Not many. Is it a pain? yes. If we were locked into not being able to change the number easily could I sleep ok if we didn't change it? yes (but I have young kids; I can always sleep ok). Robert> So, what I proposed is that we leave a little wiggle room in Robert> the versioning. Can't do much about 5.1 and 5.2 - they are Robert> already sandwiched (well, 5.1 isn't yet, but it's about to Robert> me. More on that in a sec). But we can make room for 5.3. I Robert> proposed that we reserve room for 10 update, not because I Robert> think we'll need that many, but because it's a nice round Robert> number and it's better to be safe than sorry. That would mean Robert> using '20' instead of '11' for 5.4, and '30' for 5.5, etc. Ugggg.... I'll need to let that one sit in my head a bit. -- Wes Hardaker Sparta, Inc. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
