On 1/9/12 1:39 PM, Balint Reczey wrote:
> Hi Gerald,
>
> On 01/09/2012 07:56 PM, Gerald Combs wrote:
>> The ABI change is the result of fixing a bug. If we revert the change
>> the ZigBee ZCL dissector will revert back to its previous broken
>> behavior and packet-zbee-zcl.h will have incorrect definitions.
>> Shouldn't we change the libwireshark version from 2:0:1 to 2:1:0 instead?
> I don't know how important the ZigBee change is, but generally bumping
> the major version of a library is something I would avoid.
> After releasing 1.8.0 we should definitely avoid it because we will
> probably bump the major version in 1.8.0 and bumping it in 1.6.x would
> result a collision.
>
> As a not too nice solution we can release 1.6.4 with a known ABI
> breakage what is still better than breaking the ABI more like we did in
> the past.
Oops. That should be "2:0:1 to 2:1:1". That is, increment the revision
only. That at least provides a hint that something changed.
> I would prefer not breaking the ABI and not releasing the ZigBee fix
> because this would be a clean solution and users can always download the
> automated builds to get the latest correct dissector.
Users *can't* always download the latest build. Some environments are
tightly controlled and standardize on the latest stable or a specific
release, period. In one extreme case I received an email from someone
trying to use 0.99.7 on Windows 7 because his IT group hadn't validated
newer releases of Wireshark.
I'd rather fix a dissector bug and break the API. In this case there are
presumably more people analyzing ZigBee traffic than writing ZigBee
dissector code.
> Generally I would prefer releasing only stability/security/build fixes
> in the stable branch to minimize the probability of introducing new bugs
> and incompatibilities.
This is one of the drawbacks of our release cycle. If we don't backport
fixes people have to live with dissector bugs for a year or more.
