4 ms·

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

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.

lolpython 5y ago
> They do not break it every release 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.
- minusf 5y ago
  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.

lolpython 5y ago

> They do not break it every release 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.

minusf 5y ago
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.