You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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).
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.
After
v0.6.1v0.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.1v0.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
The text was updated successfully, but these errors were encountered: