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
The last time this issue was raised on this project was November 2015 (over 2 years ago) (#268). I think it's time to reopen the conversation.
I'd like to quote the argument directly from this post on a different project (graphql/graphql-js#1005):
I think it's time to move to 1.0+ versioning so that we can actually use the version number to transmit meaningful semantic information (ie. that a "major" version bump is a compatibility-breaking change). Our current version numbers (of the form v0.x.y) transmit basically nothing, because:
Major version zero (0.y.z) is for initial development. Anything may change at any time.
This entry from the Semver FAQ is also helpful:
How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.
I think all of those apply to this package, so let's do it with the next release.
I'm specifically making the argument that it's long overdue for AVA to release v1 so the version number can transmit meaningful semantic information since if you have a stable API on which users have come to depend, you should be 1.0.0.
I realize there is a 1.0.0 milestone, but there is no roadmap for that release (2 week, 2 months or 2 years out?). In the meantime, with over 12k stars, AVA is being used by a large user base who depend on a stable API to test production applications.
I propose moving to 1.0.0 as soon as possible (before Babel 7 support even, as that would be a major or minor version bump). Rename the 1.0.0 milestone to something meaningful and unattached to a version number. Under semver, version numbers do not drive features, but are defined by what bug fixes and API changes are released in any version.
Users, please give feedback here if this is important to you, and maintainers, please explain why this should be delayed any longer. Thanks.
The text was updated successfully, but these errors were encountered:
I agree, it's way overdue. There are things we really wanted to fix before 1.0.0, like #1047, but we just didn't have enough time. I think it makes sense to do it after the Babel 7 release (which will be out soon) We don't want to do 2.0.0 a couple of weeks after 1.0.0.
Sure, I don't particularly care about version numbers anyway.
I think historically most releases have contained breaking changes. Most issues in the current 1.0 milestone also require breaking changes. I thus don't foresee us doing fewer releases with broking changes, but it would encourage doing more releases when smaller fixes or features land.
The last time this issue was raised on this project was November 2015 (over 2 years ago) (#268). I think it's time to reopen the conversation.
I'd like to quote the argument directly from this post on a different project (graphql/graphql-js#1005):
I'm specifically making the argument that it's long overdue for AVA to release v1 so the version number can transmit meaningful semantic information since if you have a stable API on which users have come to depend, you should be 1.0.0.
I realize there is a 1.0.0 milestone, but there is no roadmap for that release (2 week, 2 months or 2 years out?). In the meantime, with over 12k stars, AVA is being used by a large user base who depend on a stable API to test production applications.
I propose moving to 1.0.0 as soon as possible (before Babel 7 support even, as that would be a major or minor version bump). Rename the 1.0.0 milestone to something meaningful and unattached to a version number. Under semver, version numbers do not drive features, but are defined by what bug fixes and API changes are released in any version.
Users, please give feedback here if this is important to you, and maintainers, please explain why this should be delayed any longer. Thanks.
The text was updated successfully, but these errors were encountered: