Hi Jason, Indeed, not so easy to find. The roadmap[1] states the intention to have a decent snapshot of the current developments in 3.1 posted as development build on the front page at about July 18th.
Thanks, Jaap [1] https://wiki.wireshark.org/Development/Roadmap <https://wiki.wireshark.org/Development/Roadmap> > On 28 Jun 2019, at 15:35, Jason Cohen <kryojen...@gmail.com> wrote: > > >> See the automated build section, dev builds for Windows and OSX: > >> https://www.wireshark.org/download/automated/ > >> <https://www.wireshark.org/download/automated/>. > > >> These builds are produced when a merge is made to the appropriate master > >> branch. > > The point wasn't for me. ;) it was for the thousands+ of users that depend > on wireshark to decode captures that will never see a line of source code or > a build bot in their life, let alone know to find build bot artifacts, or > that such a thing exists. > > On Fri, Jun 28, 2019 at 7:55 AM Graham Bloice <graham.blo...@trihedral.com > <mailto:graham.blo...@trihedral.com>> wrote: > > > On Fri, 28 Jun 2019 at 13:49, Jason Cohen <kryojen...@gmail.com > <mailto:kryojen...@gmail.com>> wrote: > All fair points. I won't push any further. > > >> My pulled from the air guess is the set of users that need these > >> incremental dissector\protocol changes is much smaller than the entire set > >> of users, and their needs are served by the development branch. > > Yes, the set of users is much smaller than the entire set of users, but not > insignificant. However, the primary path they follow for support of the > F5ethtrailer dissector is F5, not Wireshark.org. > > And development branch? By this are you meaning to pull from source and > build? This definitely seems to be a smaller sub-set of users. The website > doesn't make it appear that there is even a development branch to be had. > The downloads area states: > > The current stable release of Wireshark is 3.0.2. It supersedes all previous > releases. You can also download the latest development release (3.0.0rc2) > [which was built 22 Feb, 2019 if you go searching for it] and documentation. > > If there was actually a development release to be had that was accessible to > the non-compiling public it may be less of a pain point. > > > See the automated build section, dev builds for Windows and OSX: > https://www.wireshark.org/download/automated/ > <https://www.wireshark.org/download/automated/>. > > These builds are produced when a merge is made to the appropriate master > branch. > > Regards, > Jason > > > On Fri, Jun 28, 2019 at 4:21 AM Graham Bloice <graham.blo...@trihedral.com > <mailto:graham.blo...@trihedral.com>> wrote: > > > On Fri, 28 Jun 2019 at 06:50, Pascal Quantin <pas...@wireshark.org > <mailto:pas...@wireshark.org>> wrote: > Hi, > > Le ven. 28 juin 2019 à 06:06, Anders Broman <a.broma...@gmail.com > <mailto:a.broma...@gmail.com>> a écrit : > > > Den fre 28 juni 2019 00:44Jason Cohen <kryojen...@gmail.com > <mailto:kryojen...@gmail.com>> skrev: > The question about about weather or not adding dissection of additional > information in a dissector is an enhancement or a bug; I think this is kind > of a grey area. If a dissector doesn't completely dissect a header, would a > patch that completes it be considered fixing it? Does it switch between a > fix and enhancement if the reason the field is missing is either a wrong > offset, or a missing proto_tree_add_item statement? > > How about handling vendor specific decodes? Particularly where the vendor > formerly provided a plugin (under an open source license) and kept it up to > date as formats and data changed. When Wireshark.org opted to pull a version > of it into libwireshark (which is a good idea) negatively impacts the release > of updates. Wireshark is not beholden to a vendors release cycle and a > vendor isn't beholden to Wiresharks. But when they do not coincide, > functionality that would readily be available is now blocked and delayed. > Furthermore, with the inclusion of the now incomplete dissector it makes it > unmanageable to provide the full vendor functionality as a plugin. > > I think there should be some level of flexibility to the inclusion of > dissector updates under these circumstances. > > As a specific example I am referring to: > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15876 > <https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15876> > > Jason > > It's a slippery slope either way. One can also argue that using the > development version is a possibility. At one point Ubuntu was not taking our > minor versions but rader did their own with security fixes only. So there's > different views on the subject. > > I'm not opposed to make an exception in this case however as the change is > small. What does other people think? > > Personally I consider adding new fields / new versions of a protocol as being > an enhancement (that's what I do for the dissectors I maintain). If we do an > exception here, how will we handle the next request and justify if we refuse > the backport? We might open a can of worms here. > The development builds are most of the time stable enough for a day to day > use. > > Just my 2 cents, > Pascal. > > I think the aim of the policy is to keep the "stable" release as stable as > possible, we all know that collateral damage from making a change is possible > and the policy aims to reduce this. I have quibbled in the past with changes > being back-ported that seem to me to be enhancements for this reason. > > My pulled from the air guess is the set of users that need these incremental > dissector\protocol changes is much smaller than the entire set of users, and > their needs are served by the development branch. > > As noted by Pascal, the development branch is (usually) quite stable and it's > been my daily driver for a number of years. > > -- > Graham Bloice > > -- > Graham Bloice > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org > <mailto:wireshark-dev@wireshark.org>> > Archives: https://www.wireshark.org/lists/wireshark-dev > <https://www.wireshark.org/lists/wireshark-dev> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > <https://www.wireshark.org/mailman/options/wireshark-dev> > mailto:wireshark-dev-requ...@wireshark.org > <mailto:wireshark-dev-requ...@wireshark.org>?subject=unsubscribe > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
