As the author of a library, I care very much about the minor and patch numbers: when you report a bug to me, I want to know exactly which build you're using. Bu

As the author of a library, I care very much about the minor and patch numbers: when you report a bug to me, I want to know exactly which build you're using. But I don't want that to impact the major/minor release number, which document compatibility. Eg: releases 2.4.0.0, 2.4.1.4, and 2.4.0.3, are all equally compatible and have the same API. They are all version 2.4, and any software that uses them only needs to express a dependency on v2.4. But they're all different builds with internal changes (that don't alter the API), and if you report a bug I need to know which of those builds you're using. If they were numbered 2.4, 2.5, and 2.6, I guess I'd know the build, but I'd lose some flexibility in expressing the API compatibility. I like being able to say that anything which works with 2.x will also work with 2.x+, where 2.x+ might add features but will not remove them. However, 3.0 might remove API methods or alter the semantics of existing methods. A single compatibility number doesn't let you express that.