So, we've done the 'right' thing with respect to libtool versioning now, but
we seem to have painted ourselves into a corner. Starting with some background
material, here are the comments regarding updating the versions from
Makefile.top:
# use libtool versioning the way they recommend.
# The (slightly clarified) rules:
#
# - If any interfaces/structures have been removed or changed since the
# last update, increment current, and set age and revision to 0. Stop.
#
# - If any interfaces have been added since the last public release, then
# increment current and age, and set revision to 0. Stop.
#
# - If the source code has changed at all since the last update,
# then increment revision (c:r:a becomes c:r+1:a).
#
# Note: maintenance releases (eg 5.2.x) should never have changes
# that would require a current to be incremented.
Since our previous scheme has us use a CURRENT up to 7, we reserved a CURRENT
of 8 for 5.1.x, 9 for 5.2.x, and 10 for 5.3.x.
So, what happens when we *must* violate the assumption noted at the end? E.G.
we need to change a structure size in a maintenance release? If, for example,
we needed to change a structure in 5.2.x, the rules dictate that CURRENT
should be bumped (which would be up to 10), but 10 is already used by 5.3.x.
It has just become an issue (see the thread net-snmpd 5.3.0.1 crashes in
disman mib), so we need to come up with a solution before 5.4 goes out.
Granted, in this particular case 5.2.x is only affected on big-endian systems
that have configure with --enable-mfd-rewrites, but it could have been (or
could be) an important security issue.
So, what I proposed is that we leave a little wiggle room in the versioning.
Can't do much about 5.1 and 5.2 - they are already sandwiched (well, 5.1
isn't yet, but it's about to me. More on that in a sec). But we can make room
for 5.3. I proposed that we reserve room for 10 update, not because I think
we'll need that many, but because it's a nice round number and it's better to
be safe than sorry. That would mean using '20' instead of '11' for 5.4, and
'30' for 5.5, etc.
As a side note, we have a window here to make structure changes in 5.1.4,
since it's making a jump to '8'. Should we change the netsnmp_index len to
size_t? note that it would only affect people using array-user generated code
on 64bit platforms. Maybe others who are using net-snmp containers with
netsnmp_indexes. But none of our modules should be affected.
--
NOTE: messages sent directly to me, instead of the lists, will be deleted
unless they are requests for paid consulting services.
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.
-------------------------------------------------------
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
