# Platform support policy **URL:** \ **Category:** Development\ **Tags:** development\ **Created:** [October 5, 2020, 11:08am UTC](https://community.zeek.org/t/platform-support-policy/6239 "2020-10-05T11:08:48Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [October 5, 2020, 11:08am UTC](https://community.zeek.org/t/platform-support-policy/6239/1 "2020-10-05T11:08:48Z")
[I had posted this on Slack in #development originally, copying here for visibility] We now have the nice list of platforms that Zeek currently supports at: [https://github.com/zeek/zeek/wiki/Zeek-Operating-System-Support-Matrix](https://github.com/zeek/zeek/wiki/Zeek-Operating-System-Support-Matrix). We however don’t have a policy yet what platform we generally aim to support going forward. Dominik and I discussed this further the other day and came up with a proposal:     1. For each distribution, we decide on a dedicated policy which     versions we want to support at any point. A general rule of thumb     would be “the two most recent stable releases still within their     support window”. But we’d actually look at each distribution and     see what policy makes sense, including any additional dependencies     we will rely on (like devtools on CentOS). And we do     mini-request-for-comments to get feedback from users if we’re     making a reasonable choice.     2. We update CI to test those versions, and \*only\* those versions.     3. We then rely on CI to decide if changes are ok: If, e.g.,     somebody wants to use a new C++ feature, that’s ok as long as CI     passes. If it breaks CI, it won’t go in. The advantage of this is that we won’t rely on having to specify specific compiler versions, which isn’t well-defined (because things also depend on libstdc++ version, system libs, etc.), but instead on whether people can actually compile Zeek on the platforms they are using. A disadvantage is that we’ll need to spend the time to ensure our CI setup keeps matching the policies, and gets updated as distribution updates come out. Thoughts? Dominik added: ---
**Author:** ![Christian](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/christian/32/593_2.png) [@Christian](https://community.zeek.org/u/Christian)\ **Post date:** [October 7, 2020, 5:21am UTC](https://community.zeek.org/t/platform-support-policy/6239/2 "2020-10-07T05:21:37Z")
I like this a lot! At the end of the day, what matters for our builds is what the distros ship, and this covers that. Plus, it's not that hard to update the CI images to keep them current. We could put together a release calendar to remind us when it's time to update CI. I took a quick look and couldn't immediately find one. I'd be happy to put one together. Best, Christian ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [October 7, 2020, 7:37am UTC](https://community.zeek.org/t/platform-support-policy/6239/3 "2020-10-07T07:37:10Z")
Yes, that would be great. The other thing we'll need to do is define the per distribution policies. You could add a 1st stab at that to the calendar as well, or we can do it afterwards. Robin ---
**Author:** ![Christian](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/christian/32/593_2.png) [@Christian](https://community.zeek.org/u/Christian)\ **Post date:** [October 21, 2020, 9:14pm UTC](https://community.zeek.org/t/platform-support-policy/6239/4 "2020-10-21T21:14:54Z")
> Yes, that would be great. Okay, I've put one together: https://calendar.google.com/calendar/ical/c_lhhisjs5pveipq33kf8q2elack@group.calendar.google.com/public/basic.ics&rm=minimal https://calendar.google.com/calendar/embed?src=c_lhhisjs5pveipq33kf8q2elack@group.calendar.google.com&rm=minimal This includes CentOS, Debian, Fedora, FreeBSD, and Ubuntu. I tried a few things and landed on one entry per release that starts on release date and ends on (LTS, when available) EOL. The benefit is that on any given day you see directly which releases are currently supported, and a click on any of the entries shows you start & end. The downside is that every day looks crowded, and it's a bit harder to see the starts/ends (week view brings it out okay though for me). > The other thing we'll need to do is define > the per distribution policies. You could add a 1st stab at that to the > calendar as well, or we can do it afterwards. I think we've got this, too: when a new release starts, it should go into CI, and when one drops off LTS EOL, it can go. What do you think? Thanks, Christian ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [October 22, 2020, 8:40am UTC](https://community.zeek.org/t/platform-support-policy/6239/5 "2020-10-22T08:40:47Z")
> [https://bit.ly/zeek-os-calendar-ical](https://bit.ly/zeek-os-calendar-ical) > [Zeek support OS calendar](https://bit.ly/zeek-os-calendar-google) Cool, very nice! Want to start a Wiki page where we collect the pieces for our new policy? Can link to those calendars from there. > I think we've got this, too: when a new release starts, it should go into > CI, and when one drops off LTS EOL, it can go. What do you think? Yeah, though I think we'll need to discuss on per distribution basis what exactly the versions are that we want to support at any point of time (and hence have in CI), plus any additional assumptions we're making (e.g., requiring devtools-X on CentOS). That might be as easy as supporting anything currently in either release or LTS, but spelling it out in the terms of the corresponding distributions would be helpful to make sure everybody's on the same page (e.g., some phrasing of "on Ubuntu, we support the current release as well as any LTS release not EOL yet; and we assume just standard packages"). Could you give that a try on that Wiki page as well for those distros, and then we can send it around to the users' list to see if people can get behind it? One more OS to add is macOS. While nobody knows the deadlines there, we should record how far back we go in supporting previous versions, and what package management we're assuming for dependencies (Homebrew I suppose). Robin ---
**Author:** ![Amber\_Graner](https://avatars.discourse-cdn.com/v4/letter/a/e19adc/32.png) [@Amber\_Graner](https://community.zeek.org/u/Amber_Graner)\ **Post date:** [October 22, 2020, 10:37am UTC](https://community.zeek.org/t/platform-support-policy/6239/6 "2020-10-22T10:37:50Z")
Can we also do a blog post and link this to the website? This way people who are new can find it/discover it easier. Thanks, ~Amber ---
**Author:** ![Christian](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/christian/32/593_2.png) [@Christian](https://community.zeek.org/u/Christian)\ **Post date:** [October 22, 2020, 7:59pm UTC](https://community.zeek.org/t/platform-support-policy/6239/7 "2020-10-22T19:59:49Z")
Sure thing. I agree with your remaining comments, too. Best, Christian ---
**Author:** ![Christian](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/christian/32/593_2.png) [@Christian](https://community.zeek.org/u/Christian)\ **Post date:** [November 6, 2020, 4:51am UTC](https://community.zeek.org/t/platform-support-policy/6239/8 "2020-11-06T04:51:50Z")
Hi folks, Sorry for the delay here -- I've now put together a page: [https://github.com/zeek/zeek/wiki/Platform-Support-Policy](https://github.com/zeek/zeek/wiki/Platform-Support-Policy) I've also added an entry to the calendar for macOS (Catalina, using the availability of images in Cirrus CI as a driver), and I'm putting together a PR (still a draft) for bringing our CI in line with what's in that page: [https://github.com/zeek/zeek/wiki/Platform-Support-Policy](https://github.com/zeek/zeek/wiki/Platform-Support-Policy) Let me know your thoughts... Thanks, Christian ---
**Author:** ![Christian](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/christian/32/593_2.png) [@Christian](https://community.zeek.org/u/Christian)\ **Post date:** [November 6, 2020, 4:52am UTC](https://community.zeek.org/t/platform-support-policy/6239/9 "2020-11-06T04:52:55Z")
Ahem -- that was supposed to be: [https://github.com/zeek/zeek/pull/1268/](https://github.com/zeek/zeek/pull/1268/) Best, Christian ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [November 6, 2020, 10:03am UTC](https://community.zeek.org/t/platform-support-policy/6239/10 "2020-11-06T10:03:47Z")
This looks great to me. Some questions/notes: - Which of these come with additional requirements beyond just OS base packages? We should note those. What I can think of: - On CentOS, if we limit support to “full updates”, CentOS 7 will drop off soon. I’m wondering if we should use versions with maintenance updates instead? (I’m glad CentOS 6 just went out of life support 🙂 - Does anybody know if Cirrus keeps previous macOS images available? If so, I’d suggest we keep the two most recent macOS versions. Robin ---
**Author:** ![Christian](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/christian/32/593_2.png) [@Christian](https://community.zeek.org/u/Christian)\ **Post date:** [November 6, 2020, 8:27pm UTC](https://community.zeek.org/t/platform-support-policy/6239/11 "2020-11-06T20:27:48Z")
> - Which of these come with additional requirements beyond just OS base >    packages? We should note those. What I can think of: > >      - CentOS: We require devtoolset (which version?) and probably >        EPEL? I don't recall how people get some of the dependencies in >        place (bison, flex, cmake). Mhmm ... this seems a bit tricky. At least in our CI setups each platform requires some stuff to be installed to allow a build, so I'm wondering whether instead of spelling them out in the wiki page we could just point at our CI? That'd be Dockerfiles for anything Linux and prepare.sh for FreeBSD and macOS. The benefit would be that we'd maintain this in one place only. We could invest a bit of time in documenting the Dockerfiles/prepare.sh scripts so they explain these? >      - macOS: Homebrew I suppose. Yeah, worth calling out because Cirrus includes it in their image, so you won't notice it when looking purely at only our CI setups. > - On CentOS, if we limit support to "full updates", CentOS 7 will drop >    off soon. I'm wondering if we should use versions with maintenance >    updates instead? (I'm glad CentOS 6 just went out of life support 🙂 🙂 -- yes, I mislabeled that one. I actually meant to say "Maintenance Updates". Fixed in the wiki page. > - Does anybody know if Cirrus keeps previous macOS images available? >    If so, I'd suggest we keep the two most recent macOS versions. I'm definitely not the expert here but it all looks like Catalina with varying additions: > **[macOS VMs - Cirrus CI](https://cirrus-ci.org/guide/macOS/)** > > Cirrus CI is a modern Continuous Integration system built for the era of cloud computing. Cirrus CI supports Linux, Windows, macOS and FreeBSD environments as well as various cloud computing services like Kubernetes, Google Cloud, AWS and Azure. Btw I didn't include anything about architectures ... for Debian 9 we currently have a 32-bit container, for some other platforms those are still available too. Do we still care about 32-bit? Best, Christian ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [November 9, 2020, 9:41am UTC](https://community.zeek.org/t/platform-support-policy/6239/12 "2020-11-09T09:41:49Z")
> we could just point at our CI? That’d be Dockerfiles for anything > Linux and prepare.sh for FreeBSD and macOS. The benefit would be > that we’d maintain this in one place only. We could invest a bit of > time in documenting the Dockerfiles/prepare.sh scripts so they > explain these? Yeah, agree, that sounds better than maintaining the information separately. > 🙂 – yes, I mislabeled that one. I actually meant to say > “Maintenance Updates”. Fixed in the wiki page. Perfect. :). > I’m definitely not the expert here but it all looks like Catalina > with varying additions: Yeah, I saw that, but not sure if that means they are actively removing older images. I’ll see if I can find out. > Btw I didn’t include anything about architectures … for Debian 9 > we currently have a 32-bit container, for some other platforms those > are still available too. Do we still care about 32-bit? Limiting to 64-bit seems fine to me for our current CI platforms. I’m wondering about supporting ARM (32- & 64-bit for Linux, 64bit for future macOS), but looks like CI doesn’t support that yet either way: [https://github.com/cirruslabs/cirrus-ci-docs/issues/218](https://github.com/cirruslabs/cirrus-ci-docs/issues/218) Robin ---
**Author:** ![Christian](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/christian/32/593_2.png) [@Christian](https://community.zeek.org/u/Christian)\ **Post date:** [November 9, 2020, 10:16pm UTC](https://community.zeek.org/t/platform-support-policy/6239/13 "2020-11-09T22:16:47Z")
> Yeah, agree, that sounds better than maintaining the information > separately. Cool. I've updated the wiki page to refer to our CI configs for the details. > > I'm definitely not the expert here but it all looks like Catalina > > with varying additions: > > Yeah, I saw that, but not sure if that means they are actively > removing older images. I'll see if I can find out. Hah, I asked them too and they actually mentioned their email reply to you! > > > \# Question > > Hi! \[This page\](https://cirrus-ci.org/guide/macOS/#list-of-availab…le-images) lists currently available macOS images. Does this mean that you actively remove older ones, or do those continue to be available without support? I'm asking because the wording in #88 suggests that multiple releases might be available. Thanks! So it looks like we can start opening up the version window soon. Yay. I've put that in the wiki page too. Here's the PR for the corresponding updates, now out of draft state: > > > The context for this PR is our \[platform support policy\](https://github.com/zeek…/zeek/wiki/Platform-Support-Policy) discussion. It brings the current CI setups in line with what's mentioned on that page. Thanks! Christian ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [November 10, 2020, 8:39am UTC](https://community.zeek.org/t/platform-support-policy/6239/14 "2020-11-10T08:39:16Z")
> Hah, I asked them too and they actually mentioned their email reply to you! Yeah, and in a further followup email they went a bit further even and committed to generally keeping the previous base image around in the future when new macOS release come out (but not the Xcode image). > [https://github.com/zeek/zeek/pull/1268](https://github.com/zeek/zeek/pull/1268) Excellent. Look like we’re all good with our new policy. Thanks for driving this forward, Christian! Robin ---
**Author:** ![Dominik\_Charousset](https://avatars.discourse-cdn.com/v4/letter/d/ac8455/32.png) [@Dominik\_Charousset](https://community.zeek.org/u/Dominik_Charousset)\ **Post date:** [November 13, 2020, 12:44pm UTC](https://community.zeek.org/t/platform-support-policy/6239/15 "2020-11-13T12:44:08Z")
Thanks so much for tidying things up, Christian! I’m really glad to see the new policy taking shape. 👏 One more thing besides available C++ features worth tracking is CMake availability. In the CAF CI (Jenkins), I’ve made all the various compiler and CMake versions used throughout a build available as artifact. Still work in progress, but this is the current list for the Docker images (the Linux versions currently listed in the Zeek Wiki minus Fedora 33): Compiler: Clang 7.0.1 Clang 8.0.0 GNU 10.2.1 GNU 7.3.1 GNU 8.3.0 GNU 8.3.1 GNU 8.4.0 GNU 9.3.0 GNU 9.3.1 CMake: 3.10.2 3.11.4 3.13.4 3.14.7 3.16.3 3.17.1 3.17.4 3.5.1 3.7.2 I’m a bit sad to see CMake 3.5 still around (released in 2016). Anyway, "it is what it is”. Versions to watch out for in particular IMHO are 3.12 (allows target\_link\_libraries for object libraries) and 3.15 (introduced FetchContent). In any case, might be worth tracking the current lower bound for CMake and library dependencies (like OpenSSL) to know when it’s safe to drop existing workarounds or start using new features. Not sure if Cirrus CI can collect data from all builds for providing a single artifact, but otherwise one could provide a script to combine the individual artifacts locally via curl or some other means. At least CMake 3.5 seems safe as minimum requirement in Zeek/Broker for now. Already a step up from the current 3.0 dependency. 😉 Dominik ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:47pm UTC](https://community.zeek.org/t/platform-support-policy/6239/16 "2022-05-06T15:47:27Z")