Be aware that OpenBSD can, will, and often has, made breaking changes to their packet filter/firewall rule syntax. Keep that in mind if you decide to rely on this for a firewall that's remote and not practical to access but requires patch maintenance without OOB access.
Upgrading between versions might, but that requires you to manually run sysupgrade anyway, at which point you probably should be reading the release notes, which should mention it.
Do you have any examples where it happened without being mentioned in release notes, or without a version bump?
The most recent change, which user likes to complain about every chance they get, is that some invalid port ranges are now rejected instead of being incorrectly accepted.
GP didn't say that they make breaking changes without documenting them, that would be horrific. The point is that they apparently make breaking changes, which is quite a nuisance. I'd rather avoid software that doesn't attempt backwards-compatibility between major releases. It can be done.
They do not break it every release. The last one I had to be concerned about was 6.8->6.9 and I remember one breaker before that (the queue thing?). You have six months to make mostly minor changes to pf.conf before you are out of support. They release every six months and patch the last release.
The changes aren't made for the heck of it, they make a more consistent system overall with new knowledge.
No one in the comment chain claimed otherwise. Breaking changes every rand() * (6 months) is not much better than breaking changes every 1 * (6 months). It still means you have to validate your firewall configs once or twice a year and randomly need to push these changes to network appliances with the same cadence. A key benefit of application stability is not having to constantly read release notes and check if your use case is affected by the changes.
> You have six months to make mostly minor changes to pf.conf before you are out of support. They release every six months and patch the last release.
Yes, they have a schedule for rolling out breaking changes. This is a maintenance burden.
> The changes aren't made for the heck of it, they make a more consistent system overall with new knowledge.
The same is true of many breaking changes in applications and APIs broadly. A cleanly designed system does not magically make the ensuing maintenance burden disappear. We probably all agree that OpenBSD and pf are well designed but we should not ignore its costs.
all software that strives for quality and not keep old rotten stuff has deprecation cycles (python, django, etc) and i vastly prefer that to "i'll never have to touch a config file again". openbsd's deprecation cycle is just shorter than the rest of the industry. their manpower and donations are way more limited as well.
