Versioning Process

[daxpryce]

On Friday (2021-02-26), we released 0.1.0 for our first release. 🎆 🍾 etc.

Up until now, we haven't had to talk about the rules for versioning in our PRs, but we're going to have to going forward.

We follow Semver, and the short of it is:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.

I'm also saying that a major version should be triggered if we add a new direct dependency. In operational environments, new dependencies often trigger a cascade of events that have to happen and adding them is going to need to be treated with a lot of care.

On any PR that includes changes to our setup.cfg, please ensure that @bdpedigo AND @dwaynepryce are on that PR. In fact, @bdpedigo, maybe we want to re-enable the CODEOWNERS bit just for setup.cfg?

We need to be aware that every time we pull in new functionality, it's a new minor release (presuming no back-compat changes accompany it). So that means cutting a release, adding it to release notes, etc. We should also feel free to release many new minor versions - it's fine if we release weekly or even daily, as long as we're adding value and NOT BREAKING ANYTHING. That's the real key.

So, reviewers - please be looking at all PRs with a keen eye toward our semver release responsibilities, in addition to our normal process.