Comment # 13
on bug 12765
from Guy Harris
(In reply to Jeff Morriss from comment #12)
> I agree that we shouldn't have backported a change to a stable branch that
> changed the format of a column. As mentioned in the ReleasePolicy:
>
> https://wiki.wireshark.org/Development/ReleasePolicy#Rationale
>
> "stable" releases don't just mean "it doesn't crash" it is supposed to also
> mean "the interfaces don't change."
>
> But, now that it's changed I would suggest that we don't change it back (a
> 2nd interface change doesn't seem better even if it does restore
> functionality).
>
>
> That being said:
>
> 1) Why is DSCP even a column? We have custom columns for this kind of
> thing. (Also see the next comment.)
>
> 2) If you add the DSCP field as a custom column (expand the DSF field, right
> click on the DSC field, and select "Apply as Column") then you have your
> choice as to whether you see EF or 46 (right click on the custom column and
> enable or disable "Resolve Names" to change the behavior). Yes, this is
> another reason to remove the hard-coded DSC column...
3) There are columns and fields as in "a user wants to look at it on the screen
or in the printed output of TShark" and there are columns and fields as in "I
want to feed this to a program to process".
I'm not certain, but this appears to be complaining about the first of those,
not the second of those.
For the first of those, the main goal of changes should be to improve
readability, not to preserve compatibility - humans can learn new things
without needing code changes. Unfortunately, not all humans agree on what's
more readable or less readable.
For the second of those, compatibility is more important - and that may mean
that the output from "-T fields" and the like for a given field will be
different from the way the field is displayed, and that there may have to be
"resolved" vs. "unresolved" options for fields.
You are receiving this mail because:
- You are watching all bug changes.
