Wireshark-bugs: [Wireshark-bugs] [Bug 1377] Empty Error Dialog Box Window - 'Capture' -> 'Interf
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1377
------- Comment #12 from guy@xxxxxxxxxxxx 2007-05-04 16:52 GMT -------
No, we don't have binary patches, which I suspect is the type of patch for
which you're asking - I'm not even sure what mechanisms there would be for
patching, as it's not just a question of replacing some bytes in the file with
different bytes; it might change the sizes of routines, and thus *move*
routines otherwise not modified.
In addition, we probably wouldn't want to release a version with the *exact*
same version string in any case, as that would mean that the version number
information wouldn't indicate that you're not running the 0.99.5 release
version. That means we might draw an incorrect conclusion from the release
number, e.g. thinking that a reported problem is in the 0.99.5 release when it
might have been introduced by a change *after* that release.
So, even if we were to have a mechanism to produce builds tagged as "0.99.5"
from a source code revision later than the revision from which 0.99.5 was
built, the build would probably be tagged as "0.99.5 - svn NNNNN" with "NNNNN"
being the Subversion source control revision of the version of the source from
which it's built. I don't know what your company's policies would say about
that.
(You might want to point out to the software policy makers in your company
that, regardless of whether the version number of the program changes, the
*code* is changed from the code in the 0.99.5 release and would, in fact, be
identical other than version number strings, so, by insisting that the code be
re-certified if the version number isn't "0.99.5" but *not* insisting on it if
the version number is "0.99.5" even though the code is changed from 0.99.5, the
policy isn't accomplishing any *technically* worthwhile goal, even if it's
*bureaucratically* worthwhile.
However, as I suspect the makers of that policy might be bureaucrats, that
might not make a difference....)
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
