Hi, It's a Windows build? Then add something to VERSION_EXTRA in config.nmake.
Thanx, Jaap Makharia, Shivesh wrote: > > Hi, > > Thanks for your responses. I think I would go for option#1 as a short > term solution and option#3 for long term as I want my changes to be > finally included in Wireshark. I have another query regarding option#1. > When I send customers a custom Wireshark Installer, do I also need to > have a version numbering different from official Wireshark builds? Is > there somewhere I have to let customers/people know that is our > "private" build as opposed to what has been offcially released by > Wireshark (like in the About box or something)? > > Thanks for your help in advance. > > Regards, > > > >> #3 is probably the "best" if you're willing to share the source and >> think > the code would be of use to others. >> Advantages: >> - Less work for you in the long run. > > - Each time a new release of Wireshark comes out with changes that > you want, you'd need to release a newer >version of your "custom" > Wireshark. Or if you don't do this, would complicate things for users > that are frequent >> Wireshark users and DO want a version installed with the latest > changes. > > - Periodically changes are made that affect ALL (or a large number) > of dissectors. If that happens someone else >would most likely update > your dissector so it continues to function. Without checking in, you'll > need to figure out why >your dissector doesn't compile anymore with > newer releases. >> - Your changes will be reviewed by someone who knows more about >> Wireshark > than you do. If you've done >something badly (that will potentially > cause crashes, weird errors, will cause you headaches in the long run) > you have a >> good chance of getting feedback to help with this. >> - You have contributed back to the community, which is kind of a major > point of this project. >> - Once your code is checked in you can just direct people to download >> the > latest Wireshark instead of your own >private version. (though initially > you may have to just distribute a custom build - though you can generate > one >> automatically here using the buildbot) > >> Downsides: >> - As you say, may take longer overall to push changes to Wireshark - > possibly especially a problem if you expect >them to be updated > frequently. > >> People here tend to be fairly responsive, and won't waste your time. >> But > if you've written something badly, you >probably will be forced to > rewrite it (which may slow you down in the short term, but be good in > the long term) > > > > >> #2 is a mixed bag. Distributing code as plugins are probably more > "legal" > if you weren't willing/allowed to distribute >the sources, but that's > not a problem for you. However, plugins tend to be problematic to > maintain. >> There tend to be frequent changes in Wireshark that will break existing > plugins (so you'd potentially end up having to >compile a plugin for > each version of Wireshark that you want your dissectors to be compatible > with), and a lot of the >maintainers here aren't exactly a fan of them. > Don't expect a lot of support on getting them to work. I'd probably >> stick with either #1 if this is just some really simple project and > you're going to be distributing to a few people for >limited use, or #3 > if you want to do things "right" and save yourself work in the long run. > > > > Why not go for #1 AND #3? > > Make a bug report with your dissector(s) and while waiting for > review/commit distribute a > > Custom version. > > /Anders > > > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
