> The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge. There's also an insidiou

> The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge. There's also an insidious side effect that people tend to think of the more common semver of features than strict semver, and they associate versions with progress and effort. You could easily get to version 50.0.0 just sorting out finishing touches on the API with strict semver if you don't have good communication with the customer. Some enterprising middle manager will start asking you've spent 50 major versions worth of effort on this library or app. As a result of those effects and the unequal application of semver, I usually encourage people at work to choose other versioning schemes. Without strictly enforcing semver, there's really not a huge advantage to semver over a plain incrementing version. Incrementing versions also have the nifty feature of making it trivial to see how many versions behind you are. Or some people go with timestamped versions, which tells you how old your version is.