On Mon, Jun 26, 2000 at 11:15:45AM +0200, Juergen Schoenwaelder wrote:
> We hope to keep the API (and the ABI) stable. But the truth is that
> changes might happen, especially if work on SMI issues resumes in the
> IETF. Anyway, we have started to make proper use of library version
> numbers. It is now easy to spot whether you have the right libsmi
> version number at configure time and you can of course have multiple
> versions of the shared library around in case that is necessary.
>
> But again, we do not intent to make more API/ABI changes unless this
> is really necessary. (And I think you will face the same problem with
> UCD, right?)
There is a risk of that with UCD and CMU SNMP, but, as libsmi is only up
to 0.2, whilst UCD SNMP is up to 4.1.2, I suspected libsmi might be less
"finished" and thus more likely to change. The only
non-backwards-compatible ABI change I've seen in UCD SNMP was
unintentional.
I'd prefer to avoid getting a lot of mail to "ethereal-users" and
"ethereal-dev" saying either
1) "I tried compiling on Red Hat 7.3 but I got these errors"
due to an incompatible API change, so, if an incompatible
change *has* to occur (which I hope is rare), I'd prefer not
to find out about them via mail messages of that sort (i.e.,
hopefully we'll get warned of it in advance);
2) "I installed the RPM on my Red Hat 7.3 system and it fails
with messages about 'smiGetALife()' being an undefined
symbol" due to an incompatible ABI change, so if an
incompatible ABI change occurs, hopefully the shared library
version number will change (and, hopefully, suppliers of
RPMs/Debian packages/*BSD packages/etc. will honor that change,
although that's probably out of your control).
