Guidelines for releases about result

[mdiep]

I think @robrix answered this pretty well.

When in doubt, open an issue asking about making a release. Follow the semver versioning scheme. Create releases freely, but get consensus about major versions.

[robrix]

My rule of thumb has been something like: release when it’s convenient for you to do so (usually when it’s convenient for you to have the tag for something you use the dependency in). I don’t know whether this scales, or whether we want to be more structured about it; I’ll happily defer to consensus.

I try to avoid attaching the human significance of “big” releases like 1.0, 2.0, etc. to semver schemes, since they can operate at cross purposes. That’s not universally successful tho—users will find 1.0 to be a significant number, no matter what I might think!—and it may cause us to miss opportunities to solidify Result as the Result type. I’m not much good at marketing, in other words.

More formally, I think we should probably have some guidelines for review. Something like: in general, try not to merge without testing it. Especially don’t release without testing it. Try to remember to request tests for new API. And so forth. (Most of these are things I’ve personally messed up on this repo and others ✋)

Please don’t take my suggestions as either necessary or sufficient, however; we’ll get better Results from consensus.