Have a good release policy

[erikmannerfelt]

I'm very lazy with releases; if something new is added or I fix something I bump the "patch" part of the version (X in "0.1.X"). Since the tool is so early, any fix is arguably a major change, so it does not make sense to me to do a major bump (X in X.1.0) even when backward compatibility breaks. In the near-future or now, there should be a clear policy for this.

Copied from semver 2.0, these are their policies:

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

Thus, a bugfix should bump the patch, and a new, say filter, should bump the minor. If considerable changes to the functionality are made, the major should be bumped. However, having a 1.0.0 should arguably only exist when the tool is more mature (potentially deviating a bit from semver).

At this moment, I'm comfortable with bumping minor and patch, but not major. Perhaps when the tool has reached a more mature state, semver can be used.

[erikmannerfelt]

And add that cargo update -w needs to be run when the version changes, or else Cargo.lock is different from Cargo.toml!