search

sco1 / flake8-annotations

Flake8 Type Annotation Checking
https://pypi.org/project/flake8-annotations/
MIT License
156 stars 7 forks source link

[Meta] Versioning Scheme #24

Closed sco1 closed 5 years ago

sco1 commented 5 years ago

What versioning scheme would make sense for this package?

I'm debating between the following two options:

I'm leaning towards CalVer. Because this is a utility plugin to flake8 with nothing externally facing or backwards incompatible (flake8 compatibility is handled by version pinning), I'm finding it hard to come up with a meaningful metric to use for incrementing major/minor versions of the package; major, in particular.

One caveat to this would be the addition of error codes that would require the user to adjust their ignore settings, but I think this would be an issue with SemVer as well. This seems pretty simply solved by suffixing the error codes table in the README with something like "introduced in ..."

lemonsaurus commented 5 years ago

always been a fan of CalVer, and I am also a fan of your rationale.

MarkKoz commented 5 years ago

How will CalVer work? Will a new year/mo version be release every time a breaking change is made otherwise just increment the micro?

sco1 commented 5 years ago

Year/month doesn't imply breaking changes, it's just literally when the release is made. Micro would be incremented for releases within the month.

MarkKoz commented 5 years ago

Then in the case errors were added or removed, there'd be no way to distinguish such release from a release for a minor fix? And it would be beneficial to distinguish because accepting small updates may be desirable but not major updates which will cause new linting errors to pop up until they're ignored. That's a downside of CalVer (i.e. you have to pin to an exact version to be safe) but then what upsides would it have to SemVer?

sco1 commented 5 years ago

The SemVer alternative would be to either:

That's a downside of CalVer (i.e. you have to pin to an exact version to be safe)

Safety is relative. How often are these linting codes going to change? This is the only "breaking" change a user would have to deal with.

MarkKoz commented 5 years ago

micro: bug fixes, refactoring, performance, etc. minor: add/remove linting errors, accommodating for breaking changes in the Flake8 plugin API? major: never or move the plugin API changes one here

How often are these linting codes going to change?

Sure, not often. However, the ability to deal with it is still nice. What is there to gain by sacrificing this and using CalVer? That no thought will need to be put in to how the version is incremented? That's the best I can think of.

sco1 commented 5 years ago

We accomodate breaking changes in flake8's API by appropriately pinning our dependency on it. So that leaves us with only incrementing major versions based on error codes. Or never.

sco1 commented 5 years ago

After some more discussion we'll go with SemVer. If we don't ever go beyond 1.0.x then it's not the end of the world.