On Thu, Nov 20, 2014 at 5:03 AM, Evan Huus <eapache@xxxxxxxxx> wrote:
> There is currently a change pending backport to the 1.12 branch (long
> since committed to master) that is a non-trivial dissector upgrade.
> Normally we don't backport this kind of change, to keep the regression
> potential to a minimum for stable releases, but this situation is
> somewhat unusual. The protocol in question was still being actively
> designed and developed when the 1.12 branch was created, so the
> dissector currently in the 1.12 branch implements a basically
> abandoned version of the spec that never ended up in serious use.
>
> I am ambivalent on this right now. I don't want to cause too much
> churn on the stable branch, but I can see the argument for backporting
> it regardless. It's also worth noting that while the protocol in
> question now is relatively narrowly focused, we will likely run into
> the exact same issue soon with HTTP2 which is rather more significant.
>
> What does everyone think? Should we be conservative and forbid this
> sort of thing? Permit it, but only after some extra level of
> testing/review? Other options?
>
> Thanks,
> Evan
>
> (The change in question is https://code.wireshark.org/review/4050 but
> I'm kind of looking for a more general resolution given that we're
> going to run into this problem again.)
My opinion :
When it is some "minor change" and don't need add/change a lot of code
(< 250 lines ?), it will be ok
Avoid to add/change some new header field (hf)
in case of HTTP2, i waiting the final draft to backport fix (to be
sure there is no new frame change...)
When final draft will be available, will be no longer need a support
of old draft (all implementation follow quicky the change on HTTP2
spec)
About https://code.wireshark.org/review/4050
tfs change will be remove (it is a enhance for me), and also don't
remove the if 0 (only add stuff for support last change)
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
