Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Follow Semantic Versioning, version 1 (RFC) #1637

Closed
razor-x opened this issue Jan 14, 2018 · 3 comments
Closed

Follow Semantic Versioning, version 1 (RFC) #1637

razor-x opened this issue Jan 14, 2018 · 3 comments
Assignees
Labels
breaking requires a SemVer major release enhancement new functionality priority
Milestone

Comments

@razor-x
Copy link
Contributor

razor-x commented Jan 14, 2018

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.

@sindresorhus
Copy link
Member

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.

@novemberborn
Copy link
Member

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.

@novemberborn novemberborn added enhancement new functionality priority breaking requires a SemVer major release labels Jan 15, 2018
@novemberborn novemberborn self-assigned this Jan 15, 2018
@novemberborn novemberborn added this to the 1.0 milestone Jan 15, 2018
@novemberborn
Copy link
Member

Thanks for raising this @razor-x. Closing, since I just released a 1.0 beta! https://github.com/avajs/ava/releases/tag/v1.0.0-beta.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking requires a SemVer major release enhancement new functionality priority
Projects
None yet
Development

No branches or pull requests

3 participants