I've also seen too much of marketing is watching the project iterate too closely, it's a Ship of Theseus, and they never know when to declare a "Big Release" anyway. In six months all of the planks are different, but it happened so slowly for marketing they still think it is the same ship. Projects just get stuck in 1.x marketing version because marketing has no idea where major releases should go. They want always up to date SaaS but then are confused they can't market it like the big Waterfall adventures of yesterday.
At least with semver they might be forced to say something. I've done that a few times where the marketing version number displayed in the app is effectively just 1.{semver major}.{semver minor} and "just tell us when you want to bump that 1 to a 2 or something" getting the response "well, it hasn't really changed all that much from 1.0, has it?" and then pulling out the receipts of something like 30+ semver breaking differences in X months.
I am not sure we are talking about the same project. However, the one I am thinking of had a interesting challenge where a security issue required making the default configuration requiring a allow-list for a certain long-existing feature. This ended up going out in a patch, even though it's a breaking change. I am still uncertain what the ideal solution would have been. Following SemVer 100% would required this to be a major. However, all supported versions needed this change. Forcing users from really old majors and minors to jump to a new major with all kinds of new stuff is less than ideal. The alternative would have been to ship multiple new majors that are really just upgrades to the old minor that they are patching. WHile technically correct, also crazy.
