Hi Gerald,
On 01/09/2012 11:44 PM, Gerald Combs wrote:
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 meant the proper change in the library version would be bumping the major
version for the #define change since the ABI is not backward compatible.
There would be an alternate way, redefining the constants in the C file
in the backported fix.
This way we could keep the API unchanged and fix the bug for stock Wireshark.
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
I think IT's (and a plugin maintainer's) general expectation is that we don't
introduce big changes in stable branches and don't make non backward-compatible
changes in stable branches and this is why they approve only latest stable releases.
If we make non backward-compatible changes we surprise them in a not too funny way.
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'm not sure if we could help all people with insane constraints due to IT.
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.
It would not be a problem, if the dissector were not written in the current way
an we had a well defined external API not including the ZigBee header file.
If we had a well defined API, we could concentrate on keeping only this stable.
I would like to help the creation of a well-defined API but I'm less and less
convinced that ABI stability is something which the project would care about.
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.
There will be a group of people who want latest and an others using stable, so I
think our release cycle is fine from this POV. Especially since the quality of
automated builds is high, IMO.
Cheers,
Balint
