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 > <[email protected]>: >> On Sat, Nov 29, 2025, 7:09 AM Roland Knall <[email protected]> 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 -- [email protected] >> To unsubscribe send an email to [email protected] > _______________________________________________ > Wireshark-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
