Hi,
The question about about weather or not adding dissection of additional information in a dissector is an enhancement or a bug; I think this is kind of a grey area. If a dissector doesn't completely dissect a header, would a patch that completes it be considered fixing it? Does it switch between a fix and enhancement if the reason the field is missing is either a wrong offset, or a missing proto_tree_add_item statement?
How about handling vendor specific decodes? Particularly where the vendor formerly provided a plugin (under an open source license) and kept it up to date as formats and data changed. When Wireshark.org opted to pull a version of it into libwireshark (which is a good idea) negatively impacts the release of updates. Wireshark is not beholden to a vendors release cycle and a vendor isn't beholden to Wiresharks. But when they do not coincide, functionality that would readily be available is now blocked and delayed. Furthermore, with the inclusion of the now incomplete dissector it makes it unmanageable to provide the full vendor functionality as a plugin.
I think there should be some level of flexibility to the inclusion of dissector updates under these circumstances.
As a specific example I am referring to:
Jason
It's a slippery slope either way. One can also argue that using the development version is a possibility. At one point Ubuntu was not taking our minor versions but rader did their own with security fixes only. So there's different views on the subject.
I'm not opposed to make an exception in this case however as the change is small. What does other people think?
Personally I consider adding new fields / new versions of a protocol as being an enhancement (that's what I do for the dissectors I maintain). If we do an exception here, how will we handle the next request and justify if we refuse the backport? We might open a can of worms here.
The development builds are most of the time stable enough for a day to day use.
Just my 2 cents,
Pascal.
I think the aim of the policy is to keep the "stable" release as stable as possible, we all know that collateral damage from making a change is possible and the policy aims to reduce this. I have quibbled in the past with changes being back-ported that seem to me to be enhancements for this reason.
My pulled from the air guess is the set of users that need these incremental dissector\protocol changes is much smaller than the entire set of users, and their needs are served by the development branch.
As noted by Pascal, the development branch is (usually) quite stable and it's been my daily driver for a number of years.
--
