Documented strong compatibility guarantees

[lordmauve]

I'm a huge fan of defopt: it perfectly embodies contemporary Python idioms. I've recommended it inside my firm.

Something that concerns me is backwards-compatibility. If I upgrade defopt, it would be catastrophic if existing command line usage broke, because those command lines are saved in a thousand places, many of which are not in source control or not easily findable in source control.

It's also the case that people using defopt test their functions directly, not through defopt, so tests are less likely to cover the actual external command line.

The thing I've looked for in the documentation, and I don't see, is some kind of statement that we can expect backwards compatibility, e.g. within a major version number.

[anntzer]

I try reasonably hard to document any backwards-incompatible change (or any change, in fact) in the changelog, and to use a semver-ish versioning, but I explicitly cannot and will not make any guarantees of strict semver, because these do not make sense to me (see e.g. https://snarky.ca/why-i-dont-like-semver/, https://bernat.tech/posts/version-numbers/, https://hynek.me/articles/semver-will-not-save-you/, etc., although I do accept the fact that downstream testing of defopt integration likely doesn't make much sense). To give a concrete example, 5618766 changed help string generation (see e.g. the changed tests) -- is that a backwards incompatible change?

PS: Thanks for your appreciation of defopt :-)

[anntzer]

Closing as not actionable, but feel free to comment if you have more suggestions.