Wireshark mailing list archives
Re: Wireshark ABI stability 1.6.4 -> 1.6.5
From: Balint Reczey <balint.reczey () ericsson com>
Date: Tue, 10 Jan 2012 19:53:21 +0100
Hi Gerald, On 01/09/2012 11:44 PM, Gerald Combs wrote:
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.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.
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 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.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
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.
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.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.
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.
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.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.
Cheers, Balint ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Wireshark ABI stability 1.6.4 -> 1.6.5 Balint Reczey (Jan 08)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Gerald Combs (Jan 09)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Bill Meier (Jan 09)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Balint Reczey (Jan 09)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Balint Reczey (Jan 09)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Gerald Combs (Jan 09)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Balint Reczey (Jan 10)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Gerald Combs (Jan 10)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Balint Reczey (Jan 10)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Gerald Combs (Jan 10)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Gerald Combs (Jan 11)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Balint Reczey (Jan 12)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Gerald Combs (Jan 12)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Gerald Combs (Jan 12)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Balint Reczey (Jan 12)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Gerald Combs (Jan 12)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Bill Meier (Jan 09)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Gerald Combs (Jan 09)
- Re: Wireshark ABI stability 1.6.4 -> 1.6.5 Balint Reczey (Jan 12)