There *might* yet be an opportunity to achieve compatibility with both 4.6.0 and 4.6.1 plugins in future 4.6.x versions. The contents of the HFILL macro (embedded in the EXPFILL macro) -- specifically, the fixed "-1" value which in the the "id" field -- could allow expert_register_field_array to reliably identify whether the passed-in structure was built against 4.6.0 or 4.6.1.
The same_name_next field in plugins built with 4.6.1 would not be usable, but there's some scope for working around that issue within epan/expert.c .
I'm not (yet) claiming that it's possible to turn this into a universal fix, and any implementation could well have some unpleasant aroma to it, but under the circumstances it may be worth investigating.
--
Darius
On Sat, 29 Nov 2025, at 11:32 PM, Roland Knall wrote:
> So the idea would be to say that going forward all plugins have to be
> compatible with 4.6.1 instead of 4.6.0? Also not ideal. In my opinion,
> this is a breaking change in a major release. I agree that the original
> bugfix had to be fixed, but this is now two breaking changes instead of
> one. So from a compatibility standpoint, the commit needs to be
> reverted even if that leaves the issue in 4.6.0. And 4.6.1 needs to be
> taken off the site.
>
> The mandate has been and always was, that there are NO breaking changes
> in major. No matter if they fix things or introduce new things. From a
> reliability point of view and a "being a good partner to the industry"
> point of view, this is critical and needs to be reverted
>
> cheers
> Roland
>
> Am Sa., 29. Nov. 2025 um 13:55 Uhr schrieb John Thacker <johnthacker@xxxxxxxxx>:
>> On Sat, Nov 29, 2025, 7:09 AM Roland Knall <rknall@xxxxxxxxx> wrote:
>>> Could you add a bug-report for this? In my pov, this is a critical bug and should be addressed by 4.6.2. It might even be considered severe enough for a recall of 4.6.1. A lot of companies use our plugin structure and if this is an issue, that is a dealbreaker for a lot of them
>>
>> It's definitely not good, although that fix was needed to solve a crasher that was introduced in the 4.6.0 dev cycle. While the proper thing to do was likely to revert the offending commit instead of backporting the fix, at this point I am unsure about the best way to fix it. If there has been more than one 4.6.x release before the incompatibly it would be somewhat different, but now either way there will be exactly one 4.6 release not compatible with the others.
>>
>> John
>> _______________________________________________
>> Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
>> To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx
> _______________________________________________
> Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
> To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx