> Some changes are worth 0.01. Others are worth 0.1 or 0.05. You can still do that with semver if you want to try and encode more information and hope that peo

> Some changes are worth 0.01. Others are worth 0.1 or 0.05. You can still do that with semver if you want to try and encode more information and hope that people read your docs to understand what specifically you mean by the size of the changes. > If many changes are expected before the actual major version, either increments are lowered (say, 0.001 instead of 0.01) Planning an entire major version and how many releases you have coming up sounds rough. Why not give yourself more room? Make it two numbers not a decimal. You could then add .0 to everything. > or many changes are batched into a single release of the reasonable size. I'm not a fan of delaying releasing fixes just because changing a number is hard. But you can still do that! Just increment minor or major and set patch to 0. This also buys you the ability to patch an older minor release! I kind of get the argument against minor and patch, but think they are usefully different. I can't imagine 5 different parts. Having a reasonable standard means not having to know the preferences of 100 maintainers. Is it perfect for everyone? No. Is it fine? Sure. My originally point is that not being perfect doesn't mean it's useless.