Release v1.0.0 for more flexible [compat] ?

[hyrodium]

I understand that this package is still in development, and I am not sure about the stability of the API; however, I would like the package to have a major version number greater than 0.

Usually, adding new features to a package will change the version v0.X.Y to v0.X,Y+1, but Aqua.jl may change the version v0.X.Y to v0.X+1.0.
This is because adding a new kind of quality test in Aqua.jl may break the current tests in other packages.

Current Versioning Strategy

• v0.X.Y → v0.X.Y+1
  • Bug fixes
  • Document improvement
  • Minor improvements
  • Deprecate functions
• v0.X.Y → v0.X+1.0 (breaking)
  • Add a new kind of quality test
  • Change function names
  • Remove deprecated functions

But someone may want new features without modifying the [compat] table for Aqua.jl.
The following versioning would help these people.

Proposed Versioning Strategy

• vX.Y.Z → vX.Y.Z+1
  • Bug fixes
  • Document improvement
  • Minor improvements
• vX.Y.Z → vX.Y+1.0 (may break the current tests with a new feature, or may require updating code)
  • Deprecate functions
  • Add a new kind of quality test
• vX.Y.Z → vX+1.0.0 (breaking)
  • Change function names
  • Remove deprecated functions

With the new versioning strategy, we can update the docs like this:

[compat]
Aqua = "~1.3.0"  # Avoid new quality tests

[compat]
Aqua = "^1.3.0"  # Tests may fail with new quality tests, but no breaking changes in Aqua's API

Do you have any thoughts on this proposal?

[lgoettgens]

I am very much in favor of this approach. However, there is some cleanup which I would like to do before I want to name this package 1.0.