Release v1.0.0?

[gerlero]

After v0.6.1 v0.6.2 is registered (#62), maybe it's time to make a v1.0.0 release too? The package seems stable (see #56) and mature (5+ years) enough, and has third-party packages that rely on it (see #60).

If done right after #62 is merged and registered (so that v1.0.0 would be the same as v0.6.1 v0.6.2 ), it would also have the nice side effect of getting the version numbers in sync with the Semicorutines.jl fork.

EDIT: v0.6.1 -> v0.6.2

[Krastanov]

It is reasonable for the next breaking release to be v1. However, I would suggest that a v1 is done only on breaking (e.g. instead of v0.7), not on patch (e.g. a potential v0.6.3 should not be turned into a v1 as that would be unnecessary churn for dependents of this package).

[gerlero]

Do we foresee any breaking changes in the short/medium term? I agree on principle and would like to use the opportunity to merge some useful changes that require an API break. However, if no such change is proposed in a while, I still think releasing v1.0.0 should provide enough information to both users and maintainers that it might be worth the time it would take downstream maintainers to see that nothing is broken and merge the CompatHelper PRs.

[Krastanov]

I added a milestone with which to track potentially breaking issues that probably need to be fixed before a v1.

[Krastanov]

with the addition of #100 (what a neat number) fixing various scoping issues, this seems like the appropriate time for (technically breaking) release of 1.0.0

Should be done shortly as the various other minor fixes and PRs get merged.

[gerlero]

Thanks for all the work @Krastanov! The package is looking great as ever 👍