> I wrote "changing primary version number" instead of "using semver" on purpose. I was making a general point. I wasn’t suggesting you were advocating semver

> I wrote "changing primary version number" instead of "using semver" on purpose. I was making a general point. I wasn’t suggesting you were advocating semver specifically. > can certainly have "we changed how configuration options work" at the very least Any major change to your versioning scheme can signal that. Including having a year number as your major iteration. But what’s more valuable to your end users in these types of scenarios is documentation about the change. > Distros are so far managing that extremely well all things considered You’ve completely lost me now. It sounds like you’re trying to defend Linux distributions but my comment was neither a criticism nor was it about Linux distributions per se. These are plenty of instances where several packages are distributed as a whole. Like with multimedia applications that might ship ffmpeg, a Python scripting environment and a multitude of other components. Linux distros, of course, is another example (and one on a much bigger scale). It’s worth noting that no major distro uses semver either. Some don’t even have a minor release let alone a major version number. But their signalling around versions satisfies a different problem to what an API needs to signal. Hence my point that versioning is about sticking to a standard more than it is about trendy schemas. > The OS problem is problem of having different components with different lifecycle.... but my iptables rules are working despise the fact iptables in kernel was entirely replaced by nftables so it certainly can be done just fine. I don’t really understand your point here but I’m happy for you that your config is still working :)