search

cryptocoinjs / bs58

Base58 encoding/decoding for Bitcoin
http://cryptocoinjs.com/modules/misc/bs58/
MIT License
216 stars 48 forks source link

Why the bump to `3.0.0`? #17

Closed dcousens closed 8 years ago

dcousens commented 9 years ago

Were there breaking changes?

jprichardson commented 9 years ago

No breaking changes that I am aware of. But refactoring an entire module out into another module may have some unforeseen breaking changes. So to err on the side of caution, I thought it made sense to increment major as it is a pretty big change.

dcousens commented 9 years ago

@jprichardson not sure I understand that reasoning. Can you give an example?

I'd argue it it's not our responsibility to bump the major just because we added a dependency.

jprichardson commented 9 years ago

Approximately 90% of the code was removed from this module. Removing that amount of code could cause unforeseen break.

I'd argue it it's not our responsibility to bump the major just because we added a dependency.

As maintainers, it is our responsibility. Who else would hold this responsibility? Does it not make more sense to err on the side of caution and bump a major?

dcousens commented 9 years ago

Approximately 90% of the code was removed from this module. Removing that amount of code could cause unforeseen break.

Still curious about this, any examples? It seems like a very interesting edge case. In reference to http://semver.org/

[bump] MAJOR version when you make incompatible API changes

There is no API change, therefore, under the contracts of a SEMVER versioning system, this change is unnecessary.

Another reference to semver:

What should I do if I update my own dependencies without changing the public API? That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it's obviously a minor level increment.

In this case, unless this repository doesn't follow semver, the major version changed for reasons other than what is [typically] expected, which IMHO, is confusing.

Does it not make more sense to err on the side of caution and bump a major?

I'm not really sure what we are err'ing on the side of, there was no problem here. A dependency is what it is, and that is perfectly defined in terms of npm and the version system. What am I missing?

jprichardson commented 9 years ago

Let me ask you something...

Let's assume that a major dependency that you were using dropped support for a Node.js version that you were still supporting i.e. this dependency went from 1.x to 2.0. Upgrading this dependency would not affect the API interface in your library but would potentially (you haven't verified) cause problems for the old Node.js version that you still want to support. The question is... do you only bump the patch?

dcousens commented 9 years ago

To clarify, a library dropped support for a contextual aspect of its API (the supported node.js versions). Backwards incompatibility. Bump major.

I'd be happy with the major bump, if there was a backwards incompatibility. I'm just not sure what that is yet.

fanatid commented 8 years ago

:lock: