No, I still maintain that if you tell a developer “there’s a new version” in a marketing sense, they expect that to align with version numbering and hence breaking changes (maybe not always breaking tbh, but there’s a lot less harm in a major version bump when there aren’t any breaking changes than a breaking change without a major version bump).

I guess what I’m saying is developers / users of your lib or API are used to dealing in version numbers. So, while I think separating the compatibility schedule from the marketing schedule is a nice idea in theory, two schedules is simply more confusing — and it’s really not that hard to align the two if you accept that a breaking change deserves as much of a fanfare as a new features.