If you create a file called "version.conf" in your top-level directory containing something like
enable: 1 pkg_format: MySpecialRelease-1 pkg_enable: 1 you can use "make-version.pl -p" to add "MySpecialRelease-1" to the installer name. You can use the "format" configuration line to add text to the version shown in the "About" dialog. 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 > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www.wireshark.org/lists/wireshark-dev/attachments/20090811/13fb32 > 6a/attachment.htm > > ------------------------------ > > _______________________________________________ > Wireshark-dev mailing list > [email protected] > https://wireshark.org/mailman/listinfo/wireshark-dev > > > End of Wireshark-dev Digest, Vol 39, Issue 15 > ********************************************* > > <DIV><FONT size="1"> > > E-mail confidentiality. > -------------------------------- > This e-mail contains confidential and / or privileged information belonging > to Spirent Communications plc, its affiliates and / or subsidiaries. If you > are not the intended recipient, you are hereby notified that any disclosure, > copying, distribution and / or the taking of any action based upon reliance > on the contents of this transmission is strictly forbidden. If you have > received this message in error please notify the sender by return e-mail and > delete it from your system. If you require assistance, please contact our IT > department at [email protected]. > > Spirent Communications plc, > Northwood Park, Gatwick Road, Crawley, > West Sussex, RH10 9XN, United Kingdom. > Tel No. +44 (0) 1293 767676 > Fax No. +44 (0) 1293 767677 > > Registered in England Number 470893 > Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, > United Kingdom. > > Or if within the US, > > Spirent Communications, > 26750 Agoura Road, Calabasas, CA, 91302, USA. > Tel No. 1-818-676- 2300 > > </FONT></DIV> > ___________________________________________________________________________ > 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 ___________________________________________________________________________ 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
