On Fri, 02 Sep 2005 14:13:35 -0700 Wes wrote: WH> 1) Have *every* (maintained) branch start using a new libcurrent WH> value.
That loud thump you just heard was me falling off my chair. WH> Thomas> 4) follow libtool versioning recommendations WH> Thomas> (http://www.gnu.org/software/libtool/manual.html#Versioning) WH> WH> sigh. but I don't see a better choice either. WH> WH> The problem is that I actually expect we break things a lot and that WH> even following their advice won't work well since we maintain so many WH> trees. EG, consider the agent library and how often we add stuff to WH> the structures and APIs there. It's not on sub-major releases only. Well, then we need to be better. Now that we are being stricter about more major releases (5.x) and minor releases (5.x.y, for y>0) being bug-fixes only, it shouldn't be too hard. Any fix that absolutely requires a structure change must wait for the next major release. (special exceptions for critical security updates, of course.) If we wanted to mitigate this, we could move in the direction of having the library allocate structures, instead of letting them be declared as local vars. Then we could at least add to the end of structures w/out causing problems. Probably should have done this when we started introducing all the renamed 'netsnmp_*' structures. WH> 1) Have *every* (maintained) branch start using a new libcurrent WH> value. Thus we can assign current=8 to 5.1, current=9 to 5.2 and WH> current=10 to what will be 5.3. Then update revision and age to 0 WH> for all of them and then follow the instructions. Are you sure? I know you were fairly attached to the idea of the user gleaning information from the library name, so I fully expected you to vote for the -release-info option (eg libnetsnmp-5.2.so.0). [That scheme would also allow API changes for minor releases (5.x.y) w/out worrying about bumping into versions for other releases.] The only downside to that would be that IF a new major release had no API changes, existing apps would have to be recompiled to get any benefits of the new release. Of course this opens up another can of worms: do we want to continue keeping all library versions the same? As it stands now, a new release with incompatible changes to the agent library would also result in the snmp library version being bumped, and thus existing apps wouldn't benefit from the new snmp library fixes/enhancements. -- Robert Story; NET-SNMP Junkie Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp> Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
