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

go 1.0 + comply with semver #562

Closed
wants to merge 1 commit into from
Closed

go 1.0 + comply with semver #562

wants to merge 1 commit into from

Conversation

Raynos
Copy link

@Raynos Raynos commented Jun 20, 2014

semver says

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

This means that 0.9.1 could break back compat of async, which is very sad.

async seems to be a rock solid production quality piece of software.

It's ready to go 1.0 and comply with semver, i.e. all new additions to the interface bump minor, and any breaking changes to the interface will bump major.

@rlidwka
Copy link

rlidwka commented Jun 20, 2014

1.0.1 can break b/w compat with 1.0.0 as easy as 0.9.1 can break it with 0.9.0. There is no practical difference.

@aearly
Copy link
Collaborator

aearly commented Jun 20, 2014

@rlidwka Of course it can, but if semver best practices are followed, a patch release should not introduce new bugs or features. The way to guard against regressions is a large corpus of tests, which async has. If you add a feature, make it a minor release.

The main reason behind a 1.0 release would be to signify that the API and list of features is stable, and ready for production use. Given async's popularity, and 11-month hiatus in updates last year, I'd say it's already there de facto. There's a couple open issues that would be nice to have (like forEachOf) for a a 1.0 release though.

@rlidwka
Copy link

rlidwka commented Jun 22, 2014

Of course it can, but if semver best practices are followed, a patch release should not introduce new bugs or features.

Yes, except most node.js libraries don't follow semver. They follow these semantics:

revisions = no b/c breaks
minors = b/c breaks for some
majors = b/c breaks for everyone

Async library fits here, as far as I know.

@Raynos
Copy link
Author

Raynos commented Jun 22, 2014

most node.js libraries don't follow semver.

That's a bad thing (tm).

Hence this issue is about asking the author to comply with semver for any future facing changes. There are no disadvantages to complying with semver.

@rlidwka
Copy link

rlidwka commented Jun 22, 2014

There are no disadvantages to complying with semver.

Strict semver compliance would require major version bump every second release. If you switch null to undefined, 99% of people won't even notice, but you have to increase first digit. I'm pretty sure that's a bad thing (unless you really enjoy waiting a year for an official release).

@Raynos
Copy link
Author

Raynos commented Jun 22, 2014

Yeah that's fine. just bump the major version number.

There's nothing wrong with bumping the major version number 5 times on one day. That's deprecating 5 bad features, congratulations.

@aearly
Copy link
Collaborator

aearly commented Jun 22, 2014

Also, one of the provisos of semver is before a 1.0 release, minor revs could be considered the equivalent of major revs, since it's considered "unstable". After 1.0 we'd have to be more strict.

@aearly
Copy link
Collaborator

aearly commented May 20, 2015

Version 1.0.0 published!

@aearly aearly closed this May 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants