# bro-pkg Bro version requirements
**URL:** https://community.zeek.org/t/bro-pkg-bro-version-requirements/5498
**Category:** Development
**Tags:** development
**Created:** [October 16, 2018, 7:22pm UTC](https://community.zeek.org/t/bro-pkg-bro-version-requirements/5498 "2018-10-16T19:22:22Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Vlad\_Grigorescu](https://community.zeek.org/u/Vlad_Grigorescu)
#### Post date: [October 16, 2018, 7:22pm UTC](https://community.zeek.org/t/bro-pkg-bro-version-requirements/5498/1 "2018-10-16T19:22:22Z")
It strikes me that as Bro development marches on, package maintainers don’t have great choices in terms of maintaining compatibility with multiple Bro versions. For JA3, to maintain compatibility, you have to do something like this, due to the SSL event change:
> @if ( Version::at\_least(“2.6”) )
> event ssl\_client\_hello(c: connection, version: count, record\_version:count, possible\_ts: time, client\_random: string, session\_id: string, ciphers: index\_vec, comp\_methods: vector of count) &priority=1
>
> @else
>
> event ssl\_client\_hello(c: connection, version: count, possible\_ts: time, client\_random: string, session\_id: string, ciphers: index\_vec) &priority=1
>
> @endif
That works, but I worry that the overhead of trying to maintain that will grow out of hand. I’m wondering if there’s a better mechanism for this. A naive approach might be to include an option in the package metadata, which specifies minimum/maximum Bro versions that it requires. The installer, then, would simply install the latest version that supports your Bro version.
I don’t want to overcomplicate things, but it does feel like there’s a mechanism that’s currently missing.
Any other thoughts?
–Vlad
---
### Author:  [@Jon\_Siwek](https://community.zeek.org/u/Jon_Siwek)
#### Post date: [October 16, 2018, 10:00pm UTC](https://community.zeek.org/t/bro-pkg-bro-version-requirements/5498/2 "2018-10-16T22:00:03Z")
> > @if ( Version::at\_least("2.6") )
> > event ssl\_client\_hello(c: connection, version: count, record\_version:count, possible\_ts: time, client\_random: string, session\_id: string, ciphers: index\_vec, comp\_methods: vector of count) &priority=1
> > @else
> > event ssl\_client\_hello(c: connection, version: count, possible\_ts: time, client\_random: string, session\_id: string, ciphers: index\_vec) &priority=1
> > @endif
>
> That works, but I worry that the overhead of trying to maintain that will grow out of hand.
I don't have the same worry at least at the moment. The maintenance
overhead doesn't seem that great: those are fairly trivial lines of
code to understand. The growth potential also seems low considering
we really don't have cycles to maintain past the last version of Bro
ourselves, so I wouldn't expect packagers to maintain their code to
work against all possible versions. e.g. in the already-unlikely
chance the same event introduces a breaking change in 2.7, the branch
complexity would not grow if they just throw out the 2.5 branch.
> I'm wondering if there's a better mechanism for this. A naive approach might be to include an option in the package metadata, which specifies minimum/maximum Bro versions that it requires. The installer, then, would simply install the latest version that supports your Bro version.
Interesting thought, but my hunch is it just makes the complexity
implicit instead of explicit. e.g. if metadata claims it works for
2.6, it's tricky the answer why that is, but with the code above you
can easily search for those specific areas that are version-sensitive.
I'm thinking it may be best to wait and see if there is actually a
problem (lots of people complaining) before trying to decide how to
solve anything.
- Jon
---
### Author:  [@system](https://community.zeek.org/u/system)
#### Post date: [May 6, 2022, 3:46pm UTC](https://community.zeek.org/t/bro-pkg-bro-version-requirements/5498/3 "2022-05-06T15:46:08Z")