I'm very conservative with my numbering. Sarge isn't used by lots of projects, and while, in my usage of it I've encountered no problems, I'm not making any exorbitant claims because concurrency is difficult to get right, and more exposure is needed before more confidence can be shown in the library. Also, because of the low level of exposure, it's not clear whether the API could be improved, and whether that might require backwards-incompatible changes. Most of my software is in the 0.x stage because it hasn't received wide enough exposure, except perhaps Python's logging (which was at 0.4.9.x when adopted into the Python stdlib, and of course it now follows Python version numbering). My python-gnupg project is at 0.3.6, but AFAIK people are using it to do useful work. Ditto for my distlib project, which is at 0.1.9.
I rarely break backward compatibility, since I've been on the receiving end enough times, but in the early stages of a project it sometimes can't be avoided.
Of course, it's a bit of a chicken-and-egg problem: projects won't adopt a library because it hasn't had much exposure, so it doesn't get much exposure, and round and round we go :-)
Others on this list might venture their opinion about what they think about sarge's stability. BTW there is a set of unit tests which is exercised on every commit, through integration with Travis-CI.
Regards,
Vinay Sajip