Regards,
Olivier
Le 29/11/2025 à 14:34, Roland Knall a
écrit :
Btw, NO breaking changes obviously does not work
for security issues, but in my opinion this is not a security
issue.
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
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